[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:  Future Release
Component:  Query         |     Version:  4.6
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+-----------------------------

Comment (by Dang Vu):

 Replying to [comment:5 boonebgorges]:

 > 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.


 If we use`$wp_query` as the main DTO and render everything via it, post
 objects in cache is useless.
 Anyway, I'm currently not familiar with WordPress architecture, if ''other
 functions in WP fetch data from the `'posts'` cache group'', then it makes
 sense.


 > `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.


 We should separate `update_post_meta_cache` and `update_post_term_cache`
 params and make it independent from `cache_results` param. These lines of
 code is ambiguous:

 {{{
 $this->posts = array_map( 'get_post', $this->posts );

 if ( $q['cache_results'] )
     update_post_caches($this->posts, $post_type,
 $q['update_post_term_cache'], $q['update_post_meta_cache']);
 }}}


 Since `get_post` has already added post objects to cache,
 `update_post_caches()` is unnecessary.
 Other problem is if `cache_results` is set to `false`, post metadata and
 term metadata will not be cached.


 > 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?


 No, performance is almost unnoticeable unless we're querying thousands of
 posts in a single query.


 I'm learning WordPress and find out the `cache_results` param doesn't work
 as expected so I have created this ticket. Now, I have understood why it
 didn't work. Thank for your time and hope I can see the enhancement in the
 next release!

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