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

WordPress Trac noreply at wordpress.org
Tue Aug 30 14:37:21 UTC 2016


#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
--------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:  reporter-feedback =>
 * milestone:  Awaiting Review => Future Release


Comment:

 > Are there any backwards-compatible reasons to not remove/ignore the
 parameter? The only thing I can think of is a slight performance hit if
 we're now no longer updating the metadata and/or taxonomy caches. I think
 that's acceptable.

 Currently, `cache_results` (when used properly alongside
 `update_post_meta_cache` and `update_post_term_cache`) prevents at least
 two additional cache roundtrips for each fetched post, and possibly many
 more in the case of lots of custom taxonomies. Removing the option
 altogether could cause serious performance problems in certain cases. Once
 #20875 is addressed, I think we can revisit the removal of
 `cache_results`.

 > The only reason I can think of is if the post includes some data that
 changes very often (for example - some plugin is attaching random or API
 data to a post at load time). In that case they're probably
 doing_it_wrong() and should be discouraged anyway so that we can use the
 cache properly.

 Yeah, filtering the post data pre-cache could cause problems, but I think
 that in this case the solution is to filter *post* cache. The frequency of
 updates is an argument *for* better cache leverage, not against it; if
 there are inconsistency issues in these cases, it's likely due to an
 invalidation bug, rather than the fact that the cache is being used in the
 first place.

 I'm going to move this ticket to Future Release so it can be reassessed
 post-#20875.

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


More information about the wp-trac mailing list