Edgewall Software

Opened 9 years ago

Last modified 20 months ago

#11826 new enhancement

Optimize ticket.query.execute

Reported by: anonymous Owned by:
Priority: normal Milestone: next-major-releases
Component: query system Version: 1.1.2
Severity: minor Keywords: performance
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by anonymous)

The ticket.query.execute function could be optimised somewhat…

     if self.max == 0:
            self.has_more_pages = False
            self.offset = 0
            self.has_more_pages = True
            self.offset = self.max * (self.page - 1)


            self.num_items = self._count(sql, args)

            if self.num_items <= self.max:
                self.has_more_pages = False

            if self.has_more_pages:


if self.max = 0 this: self.num_items = self._count(sql, args) is useless since if self.has_more_pages: will always be False.

So I suggest adding something like:

if self.has_more_pages: // This line
     self.num_items = self._count(sql, args)

            if self.num_items <= self.max:
                self.has_more_pages = False

            if self.has_more_pages:

That would save one sql-query which in worst case scenario could double(?) the execution time I suppose

Attachments (0)

Change History (10)

comment:1 by anonymous, 9 years ago

Description: modified (diff)

comment:2 by Christian Boos, 9 years ago

Milestone: 1.1.3
Priority: normallow
Severity: normalminor
Version: 1.1.2

Well, we compute .num_items not just to set the .has_more_pages flag, but also because we need that information. The question is if in this particular case (which I admit we don't use or test much, because it's probably a bad idea to not paginate the results), we could retrieve the .num_items from the main query. It looks like we could easily do that.

comment:3 by anonymous, 9 years ago

Then it might have been my bad, since it just returns the result i didn't think of that it could be used later…

However it might be better/more optimized to calculate num_items/has_more_pages on demand.

I noticed this when I used the xmlrpcplugin with max=0, so the count query was a bit .. unexpected…

comment:4 by Jun Omae, 9 years ago

I've had the same issue while developing th:ExcelDownloadPlugin. The plugin provides download in excel format from query page and converts always all tickets from query (max parameter is ignored) to excel format.

Currently, the plugin overrides _count instance method of Query instance to prevent SELECT COUNT(*) query. See source:exceldownloadplugin/0.12/tracexceldownload/ticket.py@13866:180-188#L163.

comment:5 by anonymous, 9 years ago

I do understand that Query can't work perfect for everyone, but its never nice when you have to hack around it like that =/

I propose adding a separate method has_more_pages instead, so it can be calculated on demand instead

comment:6 by Ryan J Ollos, 8 years ago

Milestone: 1.1.3next-dev-1.1.x

Retargeting tickets in milestone:1.1.3 that have no owner. Please retarget as appropriate.

comment:7 by figaro, 8 years ago

Keywords: performance added
Priority: lownormal

Added keyword 'performance'. Upped priority to normal.

comment:8 by Ryan J Ollos, 8 years ago

Milestone: next-dev-1.1.xnext-dev-1.3.x

Narrowing focus for milestone:1.2. Please move ticket to milestone:1.2 if you intend to fix it.

comment:9 by Ryan J Ollos, 4 years ago

Milestone: next-dev-1.3.xnext-dev-1.5.x

Milestone renamed

comment:10 by Ryan J Ollos, 4 years ago

Milestone: next-dev-1.5.xnext-major-releases

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.