ps: forgot to mention this MDEV which is also relevant to the thread (i think) that i made about backporting the default automatic value of "table_definition_cache" from MySQL 5.6.8+ (400 + (table_open_cache / 2) and limited to 2000) instead of a fixed value of 400 : https://mariadb.atlassian.net/browse/MDEV-7261 Le 22/04/2015 00:31, Jean Weisbuch a écrit :
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!
On Apr 21, Justin Swanhart wrote:
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 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.