[wp-trac] [WordPress Trac] #10964: Improving query_posts performance

[WordPress Trac]

#10964: Improving query_posts performance
-------------------------+--------------------------------------------------
 Reporter:  buch0090     |       Owner:                        
     Type:  enhancement  |      Status:  new                   
 Priority:  normal       |   Milestone:  Awaiting Triage       
Component:  Performance  |     Version:  2.8.4                 
 Severity:  normal       |    Keywords:  has-patch tested early
-------------------------+--------------------------------------------------
Changes (by rowanbeentje):

 * cc: rowan@… (added)


Comment:

 Hi guys,

 I've been looking at this patch after we reviewed our slow query logs and
 found by far the biggest culprit to be these queries.  The principle seems
 sound - manual testing of the split to two queries shows a marked
 performance improvement.

 We're still on 2.9.2 (lots of custom plugins, and just waiting on further
 3.0.x checks in-house) so I looked at both 10964.4.diff and query.5.diff
 and created a diff against 2.9.2 so we could test it.

 A couple of comments on those previous patches:

 10964.4.diff:
     - The third argument to apply_filters when applying post-paging
 filters to the various query placeholders appears to be to differentiate
 between the standard and quick versions.  On line 2254 after applying the
 patch, I think the "true" should be "false".
 query.5.diff:
     - In the same block of post-paging filters (!), on line 2379, the
 filter arguments are malformed and appear to be missing a leading "array(
 ".
     - Line 2391 is using another malformed filter argument setup - see
 "$array( quick_distinct, &$this )".

 When testing, we found a problem which is a little more serious, and
 should probably block the release of this for the time being.  Basically,
 the $distinct, $fields, $join, $where and $groupby query arguments are
 split into two in this patch - one for the quick request, one for the
 standard request.  However, they're all initialised blank at the top of
 the function, presumably so that they're just available for filtering -
 but certain query setups can modify some of these placeholders, and not
 the quick version.  This can result in the two queries diverging; this
 also causes E_USER_NOTICES (from broken queries) if other variables which
 are NOT split by query ($orderby or $limits) are modified at the same
 time, especially when they apply to a new $join.

 I propose a quick fix for this would be to move the instantiation of
 $quick_join, $quick_where, and $quick_groupby to just before the "Apply
 post-paging filters on where and join" block, and set them to copy the
 values of $join, $where and $groupby respectively.  This maintains
 separate post-paging filters and caching-plugin filters, but ensures that
 the rest of the function logic is applied to both new queries.

 I'm happy to submit patches for 2.9.2 (just for people patching old
 installations) and trunk using this new approach if people think this is
 the right route to take.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10964#comment:39>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software