There was also a MDEV created about this very problem on MariaDB by Guillaume : https://mariadb.atlassian.net/browse/MDEV-7292 But in my opinion, this specific test is only usefull to see scalability issues or the cache warming impact but it doesnt really reflect a typical real-world usage (the original topic here) : if you use this cache its because you wont always query different tables but eventually have queries on tables already cached. I wonder what is the performance difference when the cache is warm and all tables are already in cache vs. a way too limited table cache that will have to purge LRU tables frequently. Le 21/04/2015 23:37, Sergei Golubchik a écrit :
Hi, Justin!
It is in fact, negatively scaleable without partitioning it: http://www.percona.com/blog/2009/11/16/table_cache-negative-scalability/ This doesn't directly apply to MariaDB. We didn't partition it because our table definition cache is lock-free. There were quite a few related changes in 10.0 (e.g. see MDEV-7292 and linked issues). In short, we didn't partition it, because it doesn't need to be
On Apr 21, Justin Swanhart wrote: partitioned. Not for this benchmark workload, at least.
Regards, Sergei
I think original question was about 5.5.
MySQL 5.6 has partitioned table cache, but rather to overcome the negative scalability aspect of increasing number of concurrent connections.
No version of MariaDB has partitioned table cache. At least yet.