[spotman]

Performance is great, but what is more interesting is maintaining that performance in the midst of failures and things going wrong.

I don't know anyone who chooses InnoDB and says "gee I wish it were faster". While it isn't the fastest show in town, it is a known quantity, and how it breaks is well understood.

So if I was going to use a different storage engine, would want something more than its a bit faster, in some cases.

Having said that, what a wonderful amount of work, and don't stop hacking on it!

[mey]

The most recent break I encountered was ibtmp1 exploding to 100's of GB and killing the box with InnoDB, so I'm not sure "how it breaks is well understood".

[philjohn]

Funnily enough I encountered something similar years ago on Microsoft SQL Server 2005.

Never got to the bottom of it either.

[dspillett]

A lot of cases I've seen where tempdb suddenly grows massively is an runaway Cartesian product in a query. Sometimes this is intentional but was never expected to be used on large data, but usually it is accidental and worse an inexperienced DB person has "fixed" the problem with multiplied output rows by adding "distinct" instead of fixing the query logic properly.