[development] mysql merge tables and partitioning

[Gerhard Killesreiter]

Rowan Kerr wrote:
> What about using ARCHIVE table instead of MERGE. It's basically 
> optimized for watchdog style data.
> 
> http://dev.mysql.com/doc/refman/5.1/en/archive-storage-engine.html

I don't recall right now why I didn't go with Archive, but there was a 
reason to it.

Looking at http://drupal.org/node/78503 the reason was probably that 
archive isn't in the default mysql install whereas merge seems to be.

> To me, it doesn't make sense to spend time making the db schema more 
> complicated and relying on a table type that is already deprecated (and 

The deprecation isn't in any way official and would only play a role in 
the future. Like about in three years, when we develop Drupal 10 or 11.

> implemented only by one database).

That's not true, PgSQL has a similar thing which my patch uses, thanks 
to Sammy's work.

> (Didn't people want a cleaner db 
> design for the next release?).

Didn't see an issue for this. Of course we always want our Db design to 
be as clean as possible, but when it comes to performance improvements I 
am more than just a little bit inclined to make amends.

> If you really want this type of behaviour 
> for large log tables, think about working on it from a partitioning 
> point of view which is supported by more db's (and will be more 
> future-proof).

But unusable in the here and now. I mainly worked on the patch because 
drupal.org was brought to a crawl by - among other things - slow inserts 
into big log tables. Drupal.org still runs on MySQL 4.0 (but we are in 
the process of changing that, but not to 5.1).

Cheers,
	Gerhard