The main reason to drop TokuDB would be it being redundant.  If MyRocks
and TokuDB would cover, basically, the same use case and MyRocks
would've done it better - then nobody would need TokuDB, right?

But you're saying that they have different use cases and even on the
common use case, MyRocks is not necessarily better - do I understand you
correctly? In that case we should be interesed in keeping TokuDB in
MariaDB Server, not removing it.

It's true that in general it shouldn't matter for the end-user what the storage engine is called as far it has more or less the same (needed) features and delivers comparable performance (in the end it would be great if we could have only one for all purposes and workloads :)).

But my concern is that at least currently publicly available Facebook version has several limitations ( https://github.com/facebook/mysql-5.6/wiki/MyRocks-limitations ) which (for me) would be problematic (for example no partitions, no online ddl and only row based replication (the locking is also interesting)) and seems strange since I would guess people (would) use theese engines mainly for compressing large tables (at least in some cases I can't even go back to compressed Innodb by how much the database size would inflate).

Myself have tested Rocks only as mongo-rocks in MongoDB environment but for me as a user the features the engine has for Mysql seem subpar.

Obviously there are bunch of issues with Toku and in the future RocksDB might get all the options people need - wanted to just share my opinion.

rr

_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to     : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp