OK. First off. I broke the rules. There are actually seven here.
… so here it goes.
* Smarter InnoDB checkpointing. The fuzzy checkpointing seems less than ideal. I think you could just fill up memory with data pool modifications and then checkpoint every 3-5 minutes or so writing the entire DB out to disk in one head pass. You’d be able to fully saturate the disks in this manner. Granted faster is better but our 100MBps drives only see 15-30MBps in practice.
You’d need copy on write semantics though so if you’re seeing full throughput to the disk you could really only fill memory 50% or so…
* gzip support
Right now COMPRESS and UNCOMPRESS only support zlib format. Unfortunately, this means you can’t use gzip’d data and send it directly to the client.
Oddly enough the gzip library is supported within zlib so it would be easy to implement and ship in MySQL.
You’d then be able to assemble a full gzip stream out of content in the database. This is possible since gzip is smart enough to decode multiple independent streams sent back to back (read the RFC if you don’t believe me).
* 5.1 released. Seriously. I need partitioning support and it isn’t stable. I’m also unable to reliably reproduce the crash bugs we’re having.
* Base64 encode/decode functions including +filesafe support. There are procedures available for this but I think these functions need to be in the core.
* SANE date/time support. I’m not going to hold my breath for this one though.
* Internal MySQL malloc replaced with tcmalloc. I’m not sure we’ve seen this bottleneck in production but it seems inevitable.
* Google MySQL patches integrated into MySQL 5.2 or 5.1