Yes there are situation when MyISAM is faster. However it is not as general as “all selects are faster” – MyISAM has serve problems with contention on the key cache mutex limiting scalability dramatically as well as slow access to the row data if access is done by index because it is only cached in OS cache.

What you seems to be missing is if application performance can be improved by using mix of storage engines it does not mean it is justified. Every complication has it costs and I believe for 95% of MySQL applications the performance advantages by such fine tuning in storage engines is not worth it.

This is not to mention if MySQL would be highly optimized for transactional storage engine such as Innodb the gap would be a lot less.

If so, I have to question the assumption that “for probably 95% of applications single storage engine would be good enough” if that storage engine is InnoDB. I find it hard to believe that the sort of use model I describe accounts for less than 5% of all MySQL uses.

Has this situation changed?

The points you raise are actually being worked on:

CREATE TABLE options exists in MariaDB 5.2: http://askmonty.org/wiki/Manual:Extending_CREATE_TABLE

As part of Timour’s “Query Fragment Pushdown” work (this is a set of several worklogs) in the SE summit we also discussed the issue of “normalized cost model” for the optimizer, where an engine could give info to the optimizer on which operations will be efficient and which are costly. (A more detailed explanation would be beyond my ability to write it, and space available here…) The obvious alternative would be a pluggable optimizer, but it seems preferable to have the optimizer constant, and let the engine just influence the decision.

Some other of Peter’s comments are also valid, but are not to my knowledge being addressed – for instance nobody is trying to get rid of the .frm files. Especially for “remote” engines like NDB, syncing the .frm is a hassle.

I always like the idea behind the ability to use multiple storage engines. The idea that “not all data is created equal” makes sense, and it stands to reason that the is benefit in the ability to address specific needs with a specific storage solution. But over time, a few things made me feel uncomfortable:

- if different storage engines cater to different use cases, then why is the SQL dialect, even DDL, just a fixed set? Shouldn’t we be able to configure tables backed by a particular storage with options that are specific to that engine? In the case of a storage engine plugin, shouldn’t the SQL dialect extend accordingly? Sure, there may be some table options today that apply only to a specific engine, but the syntax for these options is hard-wired in the code proper – not in any particular storage engine. Essentially this means that if you want to develop a storage engine yourself that needs specific table options, you can’t just write a plugin – you actually have to fork the server to allow the user to talk properly to your engine.

- perhaps an extension of the previous point, shouldn’t data type support be dynamic too? It seems reasonable that one of the special advantages of a particular storage engine would be that it implements particular data types. Again, if we’d want to create an engine to support a particular specific data type, we have no option but to fork the server.

- you already mentioned it, but indeed – what about the optimizer? Shouldn’t the optimizer be extensible and pluggable too? Column-oriented storage engine vendors like infobright and calpont all had to put in their optimizer next to the native one in order to benefit from their engine. Is that just a corner case? WOuld it even be possible to come up with an optimizer design that is so generic that it is even possible to fully benefit from different engines?

(I am not pretending I have any answers – just voicing concerns about the current state of the ‘pluggable’ SE)

Transactional API is only one part of the story, a very small one. Think about Optimizer for example – it has to operate entirely different for local in memory data and distributed storage engine. I recognize this is major point for Drizzle and MySQL which at certain point attracted development and user community.

First I came to write this post after serving on advisory to number of database engines, some not MySQL related at all as well as well as looking at design of NoSQL solutions as MongoDB. I was in many cases pleased how simple designs they can use because they do not have this multiple storage engine complication.

Percona Server is not going to rip away support for other storage engines, there is no point doing that without significant changes to the architecture and result obviously will not be as compatible with MySQL as we want Percona Server to be.

I’m simply wishing some thing like this would exist though we are not in position to jump into creating it right now.

Right. The bad interface for storage engine adds to the list of problems but I still believe the problems are general. How many of the items in my list does Drizzle design is posed to solve completely ?

Now regarding temporary storage for resolving queries it does not have to be handled the same way as normal operations. At least one can argue it should not. Internal temporary tables are handled just by single thread which has created them which includes all kind of concurrently. Regarding treating In memory and on disk tables equally I think Innodb could be improved in a way it does it but again I argue for a lot of users simplicity and performance in general case can be a more important than getting last possible bits of performance in niche cases.

Please do not get me wrong I’m not suggesting this as a path for Drizzle or MySQL my point is 95% of users would be served better by more tight knit solution.

PG seems significantly less buggy and significantly more responsive to bugs. (#989 I am looking at you)
PG only has a single storage engine. No multiple data dictionaries and hyper easy hot backups.
PG seems to have fewer weird issues scaling up.
BSD licence.
No conference surprise features.
No crippleware^H^H^H^H^H^H^H^H^H^H enterprise only features.