[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:
-------------------------------+----------------------
Changes (by pento):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Thank you for the extra thoughts, folks.

 I appreciate that `wp_posts` can be a bottleneck for sites that create a
 lot of CPTs. I don't think having separate tables for CPTs is the answer,
 though. While this would likely give some performance boost in some areas,
 it would significantly complicate other common tasks (for example, search,
 looking up posts by slug, as well as any sort of bulk `post_author`
 management).

 Such a change would also redefine what the `post_id` means, given that
 each table would have its own autoincrement column: `post_id` has been a
 unique identifier for the entire life of WordPress, I don't think it would
 be possible for us to change that without breaking just about every
 WordPress site in weird and subtle ways.

 Finally, the complexity of migrating existing posts to this schema change
 would be wildly error prone.

 Since this ticket was originally created, hosts have generally relaxed
 their restrictions around creating tables, so plugins that need it can
 reliably create a table appropriate to them, if needed.

 In the case of WooCommerce, [https://github.com/woocommerce/woocommerce-
 product-tables-feature-plugin/issues/137 they've explored splitting off
 tables in the past], but have run into many of the problems I've mentioned
 here. It's still something they're looking into, but it's not a simple
 problem to solve, and that's just for one plugin.

 As such, these kinds of large scale performance changes really need to be
 done on a site-by-site or plugin-by-plugin basis, rather than drastically
 increasing the complexity of all WordPress sites.

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