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

WordPress Trac wp-trac at lists.automattic.com
Fri Oct 16 18:37:27 UTC 2009


#10964: Improving query_posts performance
-------------------------+--------------------------------------------------
 Reporter:  buch0090     |       Owner:                          
     Type:  enhancement  |      Status:  new                     
 Priority:  normal       |   Milestone:  2.9                     
Component:  Performance  |     Version:  2.8.4                   
 Severity:  normal       |    Keywords:  query_posts, performance
-------------------------+--------------------------------------------------

Comment(by buch0090):

 Replying to [comment:5 scribu]:
 > So, you're first selecting the IDs and then getting all fields for those
 ids, instead of returning all the fields only for the desired posts
 directly.
 >
 > That doesn't seem a good optimisation since the SELECT clause is
 evaluated last, after the rows have been filtered. Or does this have
 something to do with indexes?
 >
 > Do you have any performance tests? If it's indeed faster, it should be
 even faster if you make it into a subquery (WP 2.9 requires MySQL 4.1 =>
 subqueries allowed).

 Load time of uncached home page that utilizes about 15 calls to
 query_posts function went down considerably. From about a minute to under
 10 seconds.

 Not sure I'm following you concerning subquery, you would still do a
 select of all fields/all rows THEN do a subquery? This fix only has the
 post ID when selecting all rows...then a second query only selects from
 the IDs of the first query.

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


More information about the wp-trac mailing list