[wp-trac] [WordPress Trac] #57373: WP_Query loading posts twice.

[WordPress Trac]

#57373: WP_Query loading posts twice.
--------------------------+---------------------------
 Reporter:  spacedmonkey  |       Owner:  spacedmonkey
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  6.1.2
Component:  Query         |     Version:  6.1
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  performance
--------------------------+---------------------------

Comment (by david.binda):

 Just wanted to share some observations from my testing of the r55035 on
 WordPress.com.

 While the changeset may reduce the number of SQL queries under the
 conditions mentioned in this ticket, there is also a side-effect which may
 lead to increased memory consumption as the `$update_meta_cache` param
 (set in `WP_Query` via `update_post_meta_cache` param) behaves differently
 in `_prime_post_caches` and `update_post_caches` functions.

 The `_prime_post_caches` function takes a list of post IDs, checks whether
 the post objects are cached (uses the `_get_non_cached_ids` function with
 `posts` passed as `$cache_key` param), and calls the `update_post_caches`
 function for non-cached post objects only (freshly fetched from the
 database, which is the source of the extra SQL query).

 The bit about filtering out post IDs of which are cached is what makes the
 difference in between the `_prime_post_caches` and `update_post_caches`,
 as the `_get_non_cached_ids` function only checks a presence of key-value
 pairs in a single cache group. In this case it's the `posts` group.

 However, such a check does not tell anything about the state of the cache
 of the post meta (and term meta) of related post objects. The post meta
 for a post object does not have to be in the cache despite the post object
 itself being there. It may be due to evictions when the persistent object
 cache backend  is used or due to `update_post_caches` function being
 called previously with `$update_meta_cache` param set to `false`.

 The `update_posts_caches` updates all the caches (post object, post meta,
 and post terms) independently on the state of any of those in the cache,
 ultimately leading to more data being fetched either from database of
 persistent cache backend.

 That said, I'm seeing an increased memory consumption with the r55035
 being applied. And while it feels like the `update_posts_caches`
 functionality is more correct, especially when the `$update_meta_cache`
 param is set to true (eg.: when `update_post_meta_cache` param of the
 `WP_Query` is used), I'm not sure whether this has been taken into
 consideration in terms of this ticket.

 To illustrate the real world impact of the issue I'm describing, a request
 which has been working fine previously now, with r55035 applied, may end
 up with an out of memory fatal error due to attempting to load a lot of
 posts and cache their post metas via `WP_Query`.

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