WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 4 weeks ago

Last modified 3 weeks ago

#53217 closed enhancement (invalid)

Remove some columns from the wp_posts table (replace them with meta values)

Reported by: alvarofranz Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: Cc:

Description

I suggest removing at least the following columns from the wp_posts table:

comment_status
ping_status
to_ping
pinged
comment_count

They only make sense for blog posts (and similar), but in the recent years I never used them. Almost all my posts are custom post types with different scopes.

I never had a problem with combining a CPT + Custom Meta values to achieve an expected functionality.

I think it's objectively true (not just an opinion) to affirm that this change would optimize the database.

If I have 10 different CPTs that don't use those fields, why having all those "pseudo meta" fields hanging around. Why not just creating them as actual meta entries when necessary?

Change History (5)

#1 @SergeyBiryukov
4 months ago

  • Component changed from General to Posts, Post Types

#2 @SergeyBiryukov
4 months ago

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just noting that backward compatibility would be a concern here. While these fields might not be used often, or at all, on some installs, removing them would unnecessarily break the installs that do use them, so we would need to find a way to avoid that to move the ticket forward.

Moving them to meta entries might also result in more complex database queries, so some performance tests before and after would be helpful to show if there is any improvement and whether the change is worth it.

#3 @alvarofranz
4 months ago

  • Type changed from defect (bug) to enhancement

@SergeyBiryukov, thanks for your attention and feedback. Really appreciate it.

Will leave here the following three things that I'm going to look into as soon as I can. Also I am new to the Make WP community and I am not familiarized yet with how things work here. If someone has more considerations or solid reasons for this being a good idea or a stupid idea, I would thank them being shared.

  1. List the core files that should be updated. Recognize the involved functions/methods and think how the change would be done in an optimal way.
  1. Backwards compatibility. Do plugins use those fields directly with plain SQL queries? If they use the builtin WP querying tools, is it possible to emulate the behavior so that plugins won't even notice the change?
  1. Performance. Once the changes have been executed in a local install, see how they affect performance.
Last edited 4 months ago by alvarofranz (previous) (diff)

#4 @alvarofranz
4 weeks ago

  • Resolution set to invalid
  • Status changed from new to closed

Got some strong points saying that this is a bad idea.

So yeah, sorry for the useless ticket ;)

#5 @desrosj
3 weeks ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.