[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