[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:  feature request    |      Status:  reopened
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion        |     Focuses:
-------------------------------+------------------------------

Comment (by russelljamison):

 Even though lots of posts would still cause a slowdown, there would still
 be plenty of  performance gains to be had as the slowdown would now be
 isolated to a specific post type.

 For example, I had a client who kept records of each project they were
 commissioned to do for their customers. There were hundreds of thousands
 of projects this company had done over their many years of operation, and
 they wanted to be able to search through all of them. I imported all of
 these projects as a custom post type, and the entire site immediately
 became sluggish. If this data was in a separate table, the only slowdown
 that would happen would be when a search was made on the project search
 page.

 The only backwards compatibility issue that I can think of with allowing a
 CPT to be moved to its own table would be with any plugins that are
 directly querying the wp_posts and wp_postmeta tables instead of using the
 built in WordPress functions. What other problems are there with backwards
 compatibility?

 Besides the performance benefits, it would become much easier to exclude
 CPTs when migrating from staging to production which is actually a huge
 benefit. I'm excited to see this ticket starting to be seriously
 considered.

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