<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The MySQL optimizer, the OS cache, and sequential versus random I/O</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/</link>
	<description>Everything about MySQL Performance</description>
	<lastBuildDate>Sat, 21 Nov 2009 05:23:57 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-511301</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Wed, 18 Mar 2009 17:51:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-511301</guid>
		<description>Oh, wow, did I really screw the math up that badly?  I believe you are right.  Funny that no one else caught it yet.

You can assume that each random I/O has to wait for the head to move, for the disk to rotate the starting point of the read under the head (1/2 of a rotation on average) and then the disk to rotate all the data under the head.  So the spindle rotation speed really dominates, and you can just estimate the random I/O off that.  You can get an absolute upper bound easily, and in practice you won&#039;t get that performance.

For sequential I/O, I have to think about that for a moment, and suddenly I&#039;m not confident in my math skills.</description>
		<content:encoded><![CDATA[<p>Oh, wow, did I really screw the math up that badly?  I believe you are right.  Funny that no one else caught it yet.</p>
<p>You can assume that each random I/O has to wait for the head to move, for the disk to rotate the starting point of the read under the head (1/2 of a rotation on average) and then the disk to rotate all the data under the head.  So the spindle rotation speed really dominates, and you can just estimate the random I/O off that.  You can get an absolute upper bound easily, and in practice you won&#8217;t get that performance.</p>
<p>For sequential I/O, I have to think about that for a moment, and suddenly I&#8217;m not confident in my math skills.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shiv</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-511232</link>
		<dc:creator>Shiv</dc:creator>
		<pubDate>Wed, 18 Mar 2009 16:02:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-511232</guid>
		<description>Baron- wonderful article.  One of those articles that establishes faith that the beast can be understood.

Question: I am not clear when at the  very end you say &quot;313 sequential reads (150 million rows / 117 bytes per row / 4096 bytes per read)&quot;.  Should&#039;nt the math  be &quot;(150 M rows*117 bytes per row)/block_size(=4096)= 4.2 M sequential reads&quot;.

If so, is there a rule of thumb for  how fast sequential reads can be done by commodity hardware ? (I am assuming that the number of 100 IOs per second refers to random I/O).

Thanks,
Shiv</description>
		<content:encoded><![CDATA[<p>Baron- wonderful article.  One of those articles that establishes faith that the beast can be understood.</p>
<p>Question: I am not clear when at the  very end you say &#8220;313 sequential reads (150 million rows / 117 bytes per row / 4096 bytes per read)&#8221;.  Should&#8217;nt the math  be &#8220;(150 M rows*117 bytes per row)/block_size(=4096)= 4.2 M sequential reads&#8221;.</p>
<p>If so, is there a rule of thumb for  how fast sequential reads can be done by commodity hardware ? (I am assuming that the number of 100 IOs per second refers to random I/O).</p>
<p>Thanks,<br />
Shiv</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: High-Performance Click Analysis with MySQL &#124; MySQL Performance Blog</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-421276</link>
		<dc:creator>High-Performance Click Analysis with MySQL &#124; MySQL Performance Blog</dc:creator>
		<pubDate>Tue, 23 Dec 2008 03:48:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-421276</guid>
		<description>[...] be fast. The star schema is essentially &quot;I admit defeat and accept table scans as a fact of life.&quot; Table scans can be better than the alternative, if the alternatives are limited, but they&#039;re still not what you need unless you&#039;re okay with long [...]</description>
		<content:encoded><![CDATA[<p>[...] be fast. The star schema is essentially &#8220;I admit defeat and accept table scans as a fact of life.&#8221; Table scans can be better than the alternative, if the alternatives are limited, but they&#8217;re still not what you need unless you&#8217;re okay with long [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dbnewz &#187; Blog Archive &#187; Cardinalité, sélectivité et distributivité d&#8217;un index MySQL : quel impact sur le plan d&#8217;exécution ?</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-351928</link>
		<dc:creator>dbnewz &#187; Blog Archive &#187; Cardinalité, sélectivité et distributivité d&#8217;un index MySQL : quel impact sur le plan d&#8217;exécution ?</dc:creator>
		<pubDate>Thu, 04 Sep 2008 22:38:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-351928</guid>
		<description>[...] Une excellente illustration des difficultés parfois rencontrées par l&#8217;optimiseur, un coup de pouce du DBA permet alors de réduire la requête de 2.5 jours à 1h ! [...]</description>
		<content:encoded><![CDATA[<p>[...] Une excellente illustration des difficultés parfois rencontrées par l&#8217;optimiseur, un coup de pouce du DBA permet alors de réduire la requête de 2.5 jours à 1h ! [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yasufumi Kinoshita</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-299242</link>
		<dc:creator>Yasufumi Kinoshita</dc:creator>
		<pubDate>Thu, 15 May 2008 05:55:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-299242</guid>
		<description>I have tried to fix 5.0 optimizer. (But I have focused on InnoDB)
My patch may solve this type of problems.

http://bugs.mysql.com/bug.php?id=36681

Regards.</description>
		<content:encoded><![CDATA[<p>I have tried to fix 5.0 optimizer. (But I have focused on InnoDB)<br />
My patch may solve this type of problems.</p>
<p><a href="http://bugs.mysql.com/bug.php?id=36681" rel="nofollow">http://bugs.mysql.com/bug.php?id=36681</a></p>
<p>Regards.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-298520</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Tue, 13 May 2008 22:00:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298520</guid>
		<description>Triffids, I don&#039;t know much about the multi-range read feature. (I say that about lots of things until I have studied it a lot).  It&#039;s unfinished, and I would bet the final implementation will be somewhat different than it is now.</description>
		<content:encoded><![CDATA[<p>Triffids, I don&#8217;t know much about the multi-range read feature. (I say that about lots of things until I have studied it a lot).  It&#8217;s unfinished, and I would bet the final implementation will be somewhat different than it is now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Triffids</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-298489</link>
		<dc:creator>Triffids</dc:creator>
		<pubDate>Tue, 13 May 2008 18:53:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298489</guid>
		<description>Cool feature ! and how MySQL optimizer chose random read (and read some blocks from cache) or use MRR (all blocks from HDD) ?</description>
		<content:encoded><![CDATA[<p>Cool feature ! and how MySQL optimizer chose random read (and read some blocks from cache) or use MRR (all blocks from HDD) ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-298472</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Tue, 13 May 2008 16:58:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298472</guid>
		<description>Triffids, see http://www.mysqlperformanceblog.com/2008/03/25/mysql-60-vs-51-in-tpc-h-queries/</description>
		<content:encoded><![CDATA[<p>Triffids, see <a href="http://www.mysqlperformanceblog.com/2008/03/25/mysql-60-vs-51-in-tpc-h-queries/" rel="nofollow">http://www.mysqlperformanceblog.com/2008/03/25/mysql-60-vs-51-in-tpc-h-queries/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Triffids</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-298459</link>
		<dc:creator>Triffids</dc:creator>
		<pubDate>Tue, 13 May 2008 16:15:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298459</guid>
		<description>And why MySQL doesn&#039;t use scattered read (multiblock read) as it do rdbms leaders ?</description>
		<content:encoded><![CDATA[<p>And why MySQL doesn&#8217;t use scattered read (multiblock read) as it do rdbms leaders ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Webadmin rövidhírek #2 at ‹Webakadémia /›</title>
		<link>http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/comment-page-1/#comment-294116</link>
		<dc:creator>Webadmin rövidhírek #2 at ‹Webakadémia /›</dc:creator>
		<pubDate>Mon, 05 May 2008 07:35:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-294116</guid>
		<description>[...] amikor nem árt a rásegítés. Egy konkrét optimalizálással kapcsolatos példát olvashatunk az operációs rendszer cache és a lemezműveletek kapcsán a MySQL Performance [...]</description>
		<content:encoded><![CDATA[<p>[...] amikor nem árt a rásegítés. Egy konkrét optimalizálással kapcsolatos példát olvashatunk az operációs rendszer cache és a lemezműveletek kapcsán a MySQL Performance [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
