[wp-trac] [WordPress Trac] #59188: WP_Posts_List_Table causes post, postmeta, and term caches to be primed for all pages in the DB on load

[WordPress Trac]

#59188: WP_Posts_List_Table causes post, postmeta, and term caches to be primed for
all pages in the DB on load
-------------------------------------+-------------------------------------
 Reporter:  kevinfodness             |       Owner:  spacedmonkey
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  6.4
Component:  Query                    |     Version:  6.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch dev-feedback   |     Focuses:  administration,
  has-unit-tests needs-dev-note      |  performance
-------------------------------------+-------------------------------------

Comment (by spacedmonkey):

 I am 100% behind the function name change. Makes sense.

 I am not sure about priming the parent cache in update_post_cache. Early
 versions of this patch did this and I removed it. In my research,
 id=>parents queries are pretty uncommon. In core it seems to mostly be
 used on the page list in wp-admin. This new cache is only useful for this
 type of query. So it is only primed on that type of query. Meaning if you
 use id=>parents lot the caches will be primed. Loading this cache whenever
 a post is loaded feels a little wasteful. I will list the reasons.

 - Most of post types are not hierarchical, meaning that this cache would
 not be needed / used.
 - This cache is only used in this query. Meaning that the cache would be
 set and loaded into memory for every post. I know that the cache is only
 an int, but if you have 100s of posts on a page, this will take up php
 memory that is not needed.
 - Adding another multi add for this cache, adds overhead. This is more
 calls to external object cache server for on unused cache.

 I think that we should consider priming this parent cache, if this cache
 is used anywhere outside WP_Query. We could consider using it in the
 following functions.

 - wp_get_post_parent_id
 - get_post_parent
 - get_post_ancestors

 Those functions could be converted to us this cache, when id is passed.
 This would save the need to cache lookup and creation of new WP_Post
 object. But I think this change should be considered in another ticket, as
 it is out of the scope of this bug fix.

 Does this make sense @peterwilsoncc ?

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