[wp-trac] [WordPress Trac] #36792: Cache Post ids in WP_Query

[WordPress Trac]

#36792: Cache Post ids in WP_Query
------------------------------------------+-----------------------------
 Reporter:  spacedmonkey                  |       Owner:
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Query                         |     Version:  3.4
 Severity:  normal                        |  Resolution:
 Keywords:  needs-unit-tests needs-patch  |     Focuses:  performance
------------------------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:  has-patch needs-unit-tests => needs-unit-tests needs-patch
 * component:  Posts, Post Types => Query
 * milestone:  Awaiting Review => Future Release


Comment:

 Thanks for opening the ticket. Caching this query would be nice.

 We need tests demonstrating invalidation for all post CRUD operations.

 The post will break `found_posts` and other parts of `WP_Query` that
 depend on the `SELECT FOUND_ROWS()` query. It may be wise for the cache to
 be structured as an array:
 {{{
 wp_cache_set( $cache_key, array(
     'results' => $results,
     'found_rows' => $found_rows,
 ), 'posts' );
 }}}

 Caching full query results has implications for 'cache_results'.
 'cache_results' is set to `false` if you're using an object cache drop-in,
 because of the unnecessary overhead of `update_post_caches()` in a context
 where most references to posts are served via the `$post` global rather
 than the cache. See #12611 for the backstory. This overhead could be
 largely mitigated by implementing `multiGet()` and `multiSet()`, but this
 is complicated because it's not fully supported by all object cache
 backends. See https://core.trac.wordpress.org/ticket/31245#comment:18 and
 ensuing discussion.

 In any case, the reasoning behind 'cache_results' when the only "results"
 being cached were post objects does not apply when we're caching the post
 IDs. I think the simple answer, for now, is that we should skip the
 'cache_results' check.

 We should also reassess the `split_the_query` check in light of the
 proposed patch. Specifically, don't see a reason why we couldn't cache the
 results of non-split queries, though we'll have to be careful about the
 way the cache key is generated. (Split queries and non-split queries ought
 to be able to share cache keys if the only difference is the
 `$wpdb->posts.*` fields clause, since we'd only be storing post IDs in the
 cache.) See #18536.

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