From: Date: July 3 2008 9:32pm Subject: Re: mutex contention for the query cache List-Archive: http://lists.mysql.com/internals/35789 Message-Id: MIME-Version: 1.0 (Apple Message framework v924) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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.