[wp-hackers] Wordpress Performance

[Ryan Lowe]

Hey All,

I've been reviewing ways to make the WP database have a smaller  
footprint (and better performance), and am looking at the following  
types of changes (these ALTER statements are against the 2.7 schema).

ALTER TABLE `comments`
   CHANGE COLUMN `comment_author_IP` `comment_author_IP` char(15) NOT  
NULL default '', /* Possibly not because of IPv6 */
   CHANGE COLUMN `comment_approved` `comment_approved` char(4) NOT  
NULL default '1', /* Current values are 0, 1, and spam ... we can't  
use enum() because of 0 and 1 */
   CHANGE COLUMN `comment_type` `comment_type`  
enum('','all','comment','pingback','trackback') NOT NULL default '',
   CHANGE COLUMN `comment_date` `comment_date` timestamp NOT NULL  
default CURRENT_TIMESTAMP,
   CHANGE COLUMN `comment_date_gmt` `comment_date_gmt` timestamp NOT  
NULL,
   DROP INDEX `comment_approved`;

ALTER TABLE `links`
   CHANGE COLUMN `link_visible` `link_visible` enum('Y', 'N') NOT NULL  
default 'Y';

ALTER TABLE `options`
   CHANGE COLUMN `autoload` `autoload` enum('yes', 'no') NOT NULL  
default 'yes';

ALTER TABLE `posts`
   CHANGE COLUMN `post_status` `post_status`  
enum('publish','draft','inherit','future','static', 'pending',  
'attachment','object', 'private') NOT NULL default 'publish',
   CHANGE COLUMN `comment_status` `comment_status`  
enum('open','closed') NOT NULL default 'open',
   CHANGE COLUMN `post_type` `post_type`  
enum('post','attachment','page') NOT NULL default 'post',
   CHANGE COLUMN `post_date` `post_date` timestamp NOT NULL default  
CURRENT_TIMESTAMP,
   CHANGE COLUMN `post_date_gmt` `post_date_gmt` timestamp NOT NULL,
   CHANGE COLUMN `post_modified` `post_modified` timestamp NOT NULL,
   CHANGE COLUMN `post_modified_gmt` `post_modified_gmt` timestamp NOT  
NULL;

ALTER TABLE `term_taxonomy`
   CHANGE COLUMN `taxonomy` `taxonomy`  
enum('category','link_category','post_tag') NOT NULL default '';

ALTER TABLE `users`
   CHANGE COLUMN `user_pass` `user_pass` char(34) NOT NULL;

I'm looking for thoughts and/or additional suggestions?  None of the  
above schema changes should require code changes but will make indexes  
smaller etc ...

Thank You,
Ryan Lowe

--
Ryan Lowe, Consultant, Percona Inc.
Skype: ryanalowe
ICQ: 457435835
24/7 Emergency Line +1 888 401 3401 ext 911
Our Services:  http://www.percona.com/services.html
Our Blog: http://www.mysqlperformanceblog.com/