<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Beware large Query_Cache sizes</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/</link>
	<description>Everything about MySQL Performance</description>
	<pubDate>Thu, 28 Aug 2008 00:02:53 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: James Day</title>
		<link>http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/#comment-95327</link>
		<dc:creator>James Day</dc:creator>
		<pubDate>Sun, 25 Mar 2007 23:59:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/#comment-95327</guid>
		<description>http://bugs.mysql.com/bug.php?id=21074 is worth watching, since it is about improvement of the time to insert the freed query cache record into the sorted list of free blocks. Flush query cache defragments the query cache, so regular flushing is one possible way of reducing the impact.

On a related topic, http://bugs.mysql.com/bug.php?id=21051 has improved the reset query cache operation and caused it to be less likely to block other queries in 5.0.25 and 5.1.12 and later. A reset might be less painful than a flush before a rare table update, even though it'll remove all of the cached queries.

The query cache design will undoubtedly be improved to better suit large cache sizes at some time. For the moment, it's intended for fairly small cache sizes, in tens rather than hundreds of megabytes.</description>
		<content:encoded><![CDATA[<p><a href="http://bugs.mysql.com/bug.php?id=21074" rel="nofollow">http://bugs.mysql.com/bug.php?id=21074</a> is worth watching, since it is about improvement of the time to insert the freed query cache record into the sorted list of free blocks. Flush query cache defragments the query cache, so regular flushing is one possible way of reducing the impact.</p>
<p>On a related topic, <a href="http://bugs.mysql.com/bug.php?id=21051" rel="nofollow">http://bugs.mysql.com/bug.php?id=21051</a> has improved the reset query cache operation and caused it to be less likely to block other queries in 5.0.25 and 5.1.12 and later. A reset might be less painful than a flush before a rare table update, even though it&#8217;ll remove all of the cached queries.</p>
<p>The query cache design will undoubtedly be improved to better suit large cache sizes at some time. For the moment, it&#8217;s intended for fairly small cache sizes, in tens rather than hundreds of megabytes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/#comment-94825</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Sun, 25 Mar 2007 10:47:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/#comment-94825</guid>
		<description>Could be. However in this case I do not see why single update would invalidate a lot of queries.
As far as I know they have millions of tables so updating each of them should invalidate only few. 

The problems with extreme number of tables is another story.</description>
		<content:encoded><![CDATA[<p>Could be. However in this case I do not see why single update would invalidate a lot of queries.<br />
As far as I know they have millions of tables so updating each of them should invalidate only few. </p>
<p>The problems with extreme number of tables is another story.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Burton</title>
		<link>http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/#comment-93438</link>
		<dc:creator>Kevin Burton</dc:creator>
		<pubDate>Fri, 23 Mar 2007 22:01:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/#comment-93438</guid>
		<description>Yeah.. I think Wordpress.com had this problem for a while as well.</description>
		<content:encoded><![CDATA[<p>Yeah.. I think Wordpress.com had this problem for a while as well.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
