Re: mutex contention for the query cache

[Brian Aker]

Hi!


On Jul 3, 2008, at 12:23 PM, Sergey Petrunia wrote:

> I suppose a storage engine could do a better job at detecting cases
> when some INSERT/UPDATE/DELETE operation didn't affect the cached
> fragments, but that seems to be a problem that is not related to poor
> qcache concurrency.  Or they are somehow related?


Bingo, this is the problem you are solving. Ever noticed with a light  
load how often (and somewhat buggily I might add) that Innodb purges  
the query cache? The mechanics of MVCC require you purge a global  
cache nearly constantly if it does not understand the current context  
of a query.

If you do the cache inside of the engine you get the advantage of  
understanding version... this buys you a cache you can use a lot more  
frequently.

There is some added benefit to also caching fragments for join  
operations but no engine today (other then Infobright) is really all  
that smart on this level.

The query cache was awesome for MyISAM/Analytic sorts of uses. Today?  
It is locking structure is far too primitive to be of any value on  
16way machines. Even if you start splitting its hash you are just  
pushing out the problem. I have seen the suggestion for using a bloom  
filter to solve some of this... but really... just let it go.

Cheers,
	-Brian

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/                     <-- Me
http://tangent.org/                <-- Software
_______________________________________________________
You can't grep a dead tree.