Fast follow: post parent ID cache

[peterwilsoncc]

https://core.trac.wordpress.org/ticket/59188

• primes parent id cache in update_post_cache()
• adds @since annotation
• renames function for clarity --- it is currently a little unclear and could imply the parent post object is cached in its entirity
• adds parameter to _prime_post_caches for priming the post parent ID caches if not already primed.

The docblock for the new parameter needs some work.

[spacedmonkey]

I don't like these changes. Changing update_post_cache, would prime a cache that is not used in most cases. This is just another memcache / memory writing call, which is wasteful.

I also don't see the point of adding a new parameter to _prime_post_caches, you can use call
_prime_post_parent_id_caches after calling _prime_post_caches

I would consider the name change of the function.

[spacedmonkey]

This cache will not be used in most caches. I don't think it is a good idea to prime it on all requests.

[peterwilsoncc]

I don't like these changes. Changing update_post_cache, would prime a cache that is not used in most cases. This is just another memcache / memory writing call, which is wasteful.

In this case, I'd question the value of introducing the new cache and instead change the shape of the cache in WP_Query calls requesting id=>parent fields to include the post parent.

wordpress-develop/src/wp-includes/class-wp-query.php

Lines 3263 to 3267 in 44e521c

	$cache_value = array(
	'posts' => $post_ids,
	'found_posts' => $this->found_posts,
	'max_num_pages' => $this->max_num_pages,
	);

For backcompat, the change of the cache's shape would need to be considered wehn getting the data.

[joemcgill]

@peterwilsoncc and @spacedmonkey, it seems like there's consensus here to commit the function name change and the @since annotation updates, but some disagreement about whether the new cache should be primed or if it should be removed and replaced with updates to the main WP_Query cache, if I'm understanding @peterwilsoncc's comment above correctly:

I'd question the value of introducing the new cache and instead change the shape of the cache in WP_Query calls requesting id=>parent fields to include the post parent

Can you two clarify what is needed to move this forward?

[spacedmonkey]

@joemcgill

What we are trying to avoid from the original ticket, was lookuping the whole post object if all you need is a parent id. This is why this new cache was introduced.

So here is something I considered in the original PR.

• We could change all id queries to get id and parent id. Then cache the parent ids in as another key in cache the array. Okay, this would help id=>parent queries, but make id queries slower, as you are requested more from the database. As id queries are FAR more common, I think we should optimize for id queries over the rare id=>parent.
• On the first run on the query, the parent cache is primed if id=>parent. These caches are not expiring. There are only invalided if you update the post or flush the whole cache. Meaning, if you are using object caching, then the first time you load the post list page in wp-admin, the parent will be primed and cache will live forever. If not there a couple of posts that were updated, the new function will do a very small query to get the missing caches.
• Priming this cache when it is not used or needed, takes resources. Adding this priming may negatively affect performance.

How about just updating the post parent cache on wp_insert_post, that way the value would be updated in cache just once and not primed all the time?