I will post that separately. In this case we just looked at Plugin vs normal release

The compression was not used I’m quite sure though I do not have the tables handy to look into it right now. We have not done profiling to see where exactly difference comes from but well the code is slightly different which is good explanation for slight performance difference.

I simply wanted to share results we had got from simple investigation effort focused on understanding what we should use in 5.1-percona builds as well as trying to understand how MySQL 5.1 will impact our customers using simple workloads (not using 5.1 features)

I know you’re not using compression for this test. (And it wouldn’t make sense anyway with an in-memory database, since compression is a way to trade off using a little more CPU (and memory possibly) to reduce disk size and most importantly i/o.) You could verify that no compression operations are being done by looking at the new Information Schema table INNODB_CMP.

So what could explain this difference? Perhaps you have some very long rows, where columns are stored completely off-page? Can you please post the CREATE TABLE commands (or tell us whether you believe this to be occurring)? Assuming both tests used tables created and indexed using the InnoDB Plugin with its new Fast Index Creation capability (which does not require Barracuda format), there should be no difference in the density of the index vs. the traditional way indexes are created.

Do you have any other ideas as to what could explain these differences between Antelope and Barracuda formats? Or between the Plugin and the built-in InnoDB? If you have the ability to do some instruction tracing/monitoring, so we could see in which routines the code is spending its time, that would be most helpful.

Last comment: while these results are interesting, without a little more data and some further analysis, it is difficult to draw any reliable conclusions.

We appreciate your interest in InnoDB and help!

As far as I understood, mysql was not able to get near 100% cpu usage during peak loads on 8 core boxes.

Did your tests confirm that?

Thanks,
Ivan

We run benchmarks at certain times using releases available at that point in time. There are tons of benchmarks which can be run and which are in the pipeline while there is only so much time we have to do them. I’m not sure we will get to repeating this benchmark for minor updates though we may do it again in a few months to see how things change.

Sure you normally do not run as such in production. This is just benchmark focusing on CPU usage only so avoiding IO… by storing data in memory.

The X axis is number of CPU cores enabled and Y is transactions per minute.