[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:  closed
 Priority:  normal                   |   Milestone:  6.4
Component:  Query                    |     Version:  6.1
 Severity:  normal                   |  Resolution:  fixed
 Keywords:  has-patch dev-feedback   |     Focuses:  administration,
  has-unit-tests needs-dev-note      |  performance
-------------------------------------+-------------------------------------
Changes (by joemcgill):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:72 flixos90]:
 > @peterwilsoncc Is this good to close now, or something else needs to be
 done here? Asking since I saw the other commit with the name change
 landing.

 The only remaining open question in this ticket is whether the newly
 introduced post parent ID cache should be primed when a post is saved, See
 [https://github.com/WordPress/wordpress-develop/pull/5443 PR #5443].

 Personally, I don't see a lot of value in this, given that for most sites,
 this cache will be non-persistent, and for sites that do have a persistent
 cache, this DB query would be more efficiently called when reading versus
 when writing data, where it would only be in the cache when some query is
 requesting it—and then, only the first time.

 I'm going to mark this as closed, and we can always add the post save
 priming later in a follow-up ticket.

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