[wp-trac] [WordPress Trac] #14558: Separate Database Table Support for Custom Post Types

[WordPress Trac]

#14558: Separate Database Table Support for Custom Post Types
-------------------------------+----------------------
 Reporter:  rahul286           |       Owner:  (none)
     Type:  enhancement        |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:  wontfix
 Keywords:                     |     Focuses:
-------------------------------+----------------------

Comment (by pento):

 I don't understand how that would help. If you're checking for changes to
 the post, don't you need to select it from the database?

 If you're caching a "last changed" value for all posts in the CPT, which
 you can look up a lot faster, there are a few problems that come to mind:
 - Dealing with race conditions, as multiple page requests could all try to
 update the JSON file at the same time (each of those page requests would
 have to wait for the JSON file to finish writing before they could read
 it, effectively a full table lock).
 - Allowing for code that doesn't use the core APIs to query the database,
 so they bypass any cache invalidation check, would be nearly impossible, I
 think. Even the best case would be extremely fragile.
 - This doesn't address that reading and parsing JSON is ''really slow'',
 relative to how fast a database is. MySQL deprecated their more generic
 version of this (the old query cache), because it had minimal benefits,
 and a whole lot of down sides.

 For providing a fast, automatically updated, minimally locked copy of the
 posts table, your best options are:

 - Use MySQL replication, and direct all of your read queries to the
 replica server. WPDB dropins like HyperDB can handle this automatically
 for you.
 - Use an in-memory cache, like memcached, which are super fast, and reduce
 load on the MySQL servers, by offloading the vast majority of read
 queries.
 - If you need to do full text searches, set up an Elasticsearch server to
 handle those requests.

 There are plugins to help you set up all of these options, they're heavily
 tested on extremely high load sites (eg, these are all things that
 WordPress.com does), and are much more reliable than any sort of process
 that would shard the posts table by arbitrary criteria.

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