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