View Issue Details

IDProjectCategoryView StatusLast Update
0021044mantisbtperformancepublic2017-01-31 04:02
Reportercproensa Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0-rc.1 
Target Version2.1.0Fixed in Version2.1.0 
Summary0021044: my view page, $t_hide_status_default consitency
Description

Looking at query times for my_view_page, all predefined filters use $t_hide_status_default, except for the "last updated" filter, which defaults to META_FILTER_NONE

I don't know if there is a strong reason to not follow all the filter and comply with that option.
The consequence is that for an instance with a big number of issues, this query (last_updated), has the longest execution time.
In a normal usage, $t_hide_status_default may have a value of status closed, and most of the issues should be in that state after its life cycle.

By applying the $t_hide_status_default option to this query, much less rows are used, the query is optimized by the table index, and execution time greatly improves.

In my test instance with 150k issues:
standard my view: Total query execution time: 4.7591 seconds
applying this modification: Total query execution time: 1.1649 seconds

TagsNo tags attached.

Relationships

related to 0006823 closedcommunity Date filter should work with "last update", too 
has duplicate 0021038 closedatrol Improvement in the database - "My View" page is very slow. 
child of 0021935 closedcproensa Filter api refactoring, manage stored filters 

Activities

cproensa

cproensa

2016-06-02 17:54

developer   ~0053253

We may want to still show closed status, for the 'last updated' filter, precisely to show recent issues that has been closed.

In that case, another option to limit that query can be to query only issues recently updated "in the last N days". That will keep the query to a small size, and short execution time.
However, i'm not sure if that condition can be performed with the standard filter definitions...

What do you think?

dregad

dregad

2016-06-03 06:11

developer   ~0053257

We may want to still show closed status, for the 'last updated' filter,
precisely to show recent issues that has been closed.

Exactly.

If you can find another way to achieve this with better performance, it would be great, but as you mentioned I'm not sure it can be achieved with the current filter API.

An alternative could be not to display the total number of issues (but that's a loss in functionality).

cproensa

cproensa

2016-06-03 06:30

developer   ~0053258

An alternative could be not to display the total number of issues (but that's a loss in functionality).

Actually,the total number of issues, as it's showed for the 'last updated' filter does not make any sense.
In this tracker, i'm sure that there aren't 12k issues that "has been recently modified".
Applying a time window to this query would make more sense, as functionality.

dregad

dregad

2016-06-03 08:08

developer   ~0053259

12k is the total number of issues in the mantisbt project

cproensa

cproensa

2016-06-03 08:13

developer   ~0053260

12k is the total number of issues in the mantisbt project

I know, but the total number displayed is in the context of the filter:
<pre>
Assigned to Me (Unresolved) (1 - 6 / 9)
Resolved (1 - 6 / 152)
Unassigned (1 - 6 / 2027)
Reported by Me (1 - 6 / 76)
</pre>

This one does not match the filter semantics:
Recently Modified (1 - 6 / 12864)

cproensa

cproensa

2016-06-03 15:18

developer   ~0053263

Adding the feature to filter by last_update field would make for a proper solution, and that is also a quite popular request...
With the sanitization i tried in PR:783 i think adding that field to the filter api is pretty effortless.

cproensa

cproensa

2016-11-06 12:31

developer   ~0054445

track as included in PR 862

cproensa

cproensa

2017-01-14 17:23

developer   ~0055123

"recently modified" view has been modified to use a filter by last update date.