I had reason to look into the extended secondary index code in MariaDB and MySQL recently, and there was one bit that I really didn’t like.
MariaDB:
share->set_use_ext_keys_flag(legacy_db_type == DB_TYPE_INNODB);
MySQL:
use_extended_sk= (legacy_db_type == DB_TYPE_INNODB);
In case you were wondering what “legacy_db_type” actually does, let me tell you: it’s not legacy at all, it’s kind of key to how the whole “metadata” system in MySQL works. For example, to drop a table, this magic number is used to work out what storage engine to call to drop the table.
Now, these code snippets basically kiss goodbye to the idea of a “pluggable storage engine” architecture. If you’re not InnoDB, you don’t get to have certain features. This isn’t exactly MySQL or MariaDB encouraging an open storage engine ecosystem (quite the opposite really).
Having the MySQL server have this incredibly basic, busy and incomplete understanding of metadata has always been a bit of a mess. The code for reading a table definition out of the FRM file really does show its age, and has fingers all through the server.
If somebody was serious about refactoring server code, you’d certainly be looking here, as this code is a major source of arbitrary limitations. However, if you have the server and the engine(s) both having separate views of what is the “correct” state of metadata you end up with a mess (anyone who has had InnoDB be out of sync with FRMs knows this one). I worry that the FRM code will be replaced with something even less understandable by humans, again making the mistake that the server knows the state of the engine better than the engine does.
See Also:
- Sergey Petrunia’s blog on the topic of extended keys: http://s.petrunia.net/blog/?p=74
- Sergey Glukhov blogs on the MySQL implementation: http://glukhsv.blogspot.com.au/2012/12/innodb-extended-secondary-keys.html
Valerii Kravchuk liked this on Facebook.
Matt Lord liked this on Facebook.
New #mysql planet post : Some storage engine features you only get if you’re InnoDB http://t.co/2Wd8vJRgwX
I named that variable with the intent to get rid of it.
it’s gone in Drizzle if that’s any consolation :)
This is already fixed (but not released yet) in MariaDB:
http://bazaar.launchpad.net/~maria-captains/maria/5.5-hf-tokudb/revision/3769
And “legacy” means “old way of checking the table type that we should get rid of”, it’s only used in a few places now, not in any new code. This was one exception, that I’ve fixed.
Andrew Hutchings liked this on Facebook.
Laurynas Biveinis liked this on Facebook.
I wonder what is Tokutek’s take on this.
RT @stewartsmith: Some storage engine features you only get if you’re InnoDB: I had reason to look into the exten… http://t.co/wsIPYRA96F
Alysander Stanley liked this on Facebook.
We are not happy with the MariaDB and MySQL implementations of extended keys because we had to patch the open_binary_frm function to add TOKUDB to the list of storage engines that support extended keys. This is a hack. IMO, the extended keys code in MariaDB and MySQL 5.6 should be redone to query the storage engine to see if it supports extended keys. Until that is done, TokuDB requires the same extended keys patch as InnoDB.
You might be interested in following the following bug report:
http://bugs.mysql.com/bug.php?id=68469
Laurinas: this is the tokutek’s take:
https://github.com/Tokutek/mariadb/commit/4f956aca791aaa96b09ec7e69820967ffc36e7f2
I’d do the same if I’d be a storage engine developer — as little changes to the server as possible.
The race is on… can the MySQL bug be fixed first or the MariaDB fix be merged?
RT @stewartsmith: Some storage engine features you only get if you’re InnoDB: I had reason to look into the exten… http://t.co/wsIPYRA96F