maria-discuss team mailing list archive

[Jean Weisbuch <jean@xxxxxxxxxx>]

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.