[wp-trac] [WordPress Trac] #64696: Real time collboration effectively disables persistent post caches while anyone edits a post

[WordPress Trac]

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by peterwilsoncc):

 Replying to [comment:117 JoeFusco]:
 > I could be wrong, but `add_post_meta()` unconditionally calls
 `wp_cache_delete( $object_id, 'post_meta' )` inside `add_metadata()`
 ([https://github.com/WordPress/wordpress-
 develop/blob/5f2be9e5a5bb4bed05fd997df8de11335b442c65/src/wp-
 includes/meta.php#L145 meta.php:145]). `update_post_meta()` does the same.

 `update_post_meta()` will bypass flushing the cache if no rows are updated
 in the resulting update query, IE if `update_post_meta( 1, 'key', 'value'
 )` is called and the value is already `value` then no flushing occurs. If
 the value was `another value` then the cache is flushed.

 `add_post_meta()` is unconditional as the row is always inserted.

 To be honest, I am not overly concerned about the single object's cache
 being flushed as the database query is `SELECT /* data */ FROM wp_postmeta
 WHERE post_id = #` and the post ID column is indexed.

 (I know this reply is delayed, I had some time AFK due to a stomach bug
 that does not respect software release cycles.)

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