[wp-trac] [WordPress Trac] #37762: cache_results parameter doesn't prevent queried posts from being added to cache

[WordPress Trac]

#37762: cache_results parameter doesn't prevent queried posts from being added to
cache
-------------------------------+------------------------------
 Reporter:  Dang Vu            |       Owner:  boonebgorges
     Type:  defect (bug)       |      Status:  assigned
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Query              |     Version:  4.6
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:  performance
-------------------------------+------------------------------
Changes (by boonebgorges):

 * keywords:   => reporter-feedback
 * owner:   => boonebgorges
 * status:  new => assigned


Comment:

 Hi @Dang Vu - Thanks for the ticket.

 > Honestly, I don't understand why WordPress needs to add queried posts to
 both the WP_Query::posts and the cache since they only exist in a single
 page load.

 If you are running a persistent object cache like Memcached, then the
 cached post objects are available across page loads. Even within a single
 pageload and without a persistent cache, other functions in WP fetch data
 from the `'posts'` cache group. `WP_Query::posts` is not intended to be a
 cache, but is a list of query results.

 `cache_results` is fairly poorly named. Introduced in [14310], it really
 means "populate all caches related to query results". This includes the
 'posts' cache as well as the taxonomy and metadata caches. See
 `update_post_caches()`. In [14665], `cache_results` was set to `false`
 when a persistent object cache is in use, because the repeated
 (unnecessary) round trips to Memcached were causing performance issues;
 see #12611. The `posts` array in `WP_Query` began to touch the 'posts'
 cache in [21559], which made `cache_results` more ambiguous: it now
 determines whether metadata and taxonomy should automatically be loaded
 into the cache, rather than the post objects. And this latter fact is
 confused by the fact that we have separate `update_post_meta_cache` and
 `update_post_term_cache` params.

 From this, I conclude that `cache_results` doesn't really do what it was
 meant to do. If anything, it should be removed altogether.

 What is the reason for wanting to prevent post objects from being loaded
 into the cache? Is it a performance issue like described in #12611? If so,
 I wonder if we could mostly mitigate the issue with cache multi-get and
 multi-set, which would dramatically reduce the number of round-trips
 necessary to load data into the cache; see #20875.

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