[wp-trac] [WordPress Trac] #26937: get_adjacent_post() should use WP_Query rather than build its own SQL query

[WordPress Trac]

#26937: get_adjacent_post() should use WP_Query rather than build its own SQL query
-------------------------+-----------------------
 Reporter:  ethitter     |       Owner:  nacin
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  3.9
Component:  Query        |     Version:  3.7
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+-----------------------
Changes (by kovshenin):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 This is now much slower than it used to be.

 ||3.8||No ext object caching||350ms||
 ||3.8||Memcached object cache||310ms||
 ||trunk||No ext object caching||1200ms||
 ||trunk||Memcached object cache||1300ms||

 I used a real import with about 600 posts from my personal blog and
 [https://gist.github.com/kovshenin/9830828 this snippet] to time them. I
 dug a bit deeper into how we use WP_Query and it seems like we have two
 separate issues.

 The first issue is WP_Query itself, it looks like most of the time is
 spent parsing the query rather than querying the database. I'm not sure
 how to address this problem.

 The second issue is the query itself. In 3.8 we do:

 {{{
 SELECT p.ID FROM wp_posts ...
 SELECT * FROM wp_posts WHERE ID = 123 LIMIT 1
 }}}

 But in trunk we currently run:

 {{{
 SELECT wp_posts.* FROM wp_posts ...
 }}}

 If you put persistent object caching in the mix then the second query in
 3.8 has a very high chance of being served from cache. With the above test
 and with [attachment:26937.3.diff] I was able to get a 300ms reduction in
 trunk with Memcached.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26937#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform