Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#11500 closed enhancement (wontfix)

Db optimization for WP 3.0

Reported by: arena Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Database Keywords:
Focuses: Cc:


Merging all meta tables (post, user, comment) into one :

CREATE TABLE `wp_metas` (
  `id`              bigint(20)     unsigned NOT NULL auto_increment,
  `blog_id`         int(11)        NOT NULL default '0',
  `object_type`     varchar(64)    NOT NULL default '',  /* 'post', 'comment', 'user', .... */
  `object_id`       bigint(20)     unsigned NOT NULL default '0',
  `key`             varchar(255)   default NULL,
  `value`           longtext,
  PRIMARY KEY  (`id`),
  KEY `object` (`blog_id`, `object_type`, `object_id`),
  KEY `key` (`blog_id`, `object_type`, `object_id`, `key`)

Change History (8)

#1 @Denis-de-Bernardy
12 years ago

Merging those tables is *NOT* an optimization. Quite the opposite, in fact.

I thought this topic had been closed for good, when we stuck to adding a shared API to access the various meta tables.

Suggesting close as wontfix.

#2 @Denis-de-Bernardy
12 years ago

It's also nearly guaranteed to break any plugin that might be using the new meta functionality with plugin-defined tables.

#3 @hakre
12 years ago

Not an enhancement as far as I see. This will create a lot of overhead for no good.

#4 @caesarsgrunt
12 years ago

This should absolutely be closed as wontfix; it is by no means an optimisation.

#5 @Denis-de-Bernardy
12 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#6 @scribu
12 years ago

Yes, this has been proposed before adding the commentmeta table and it is not the winning solution.

#7 @arena
12 years ago

even in a WP & WPµ merge (WP 3.0) ?

would have drastically reduced the number of mysql tables !

#8 @dd32
12 years ago

would have drastically reduced the number of mysql tables !

It would, However MU uses the many tables for a performance reason, and the ability to manage seperately.

The only downside of the many tables approach is that database upgrades can be hard performance-wise, But the modifications taking longer is far outweighed by the extra read-performance IIRC.

Note: See TracTickets for help on using tickets.