Comments on: The MySQL optimizer, the OS cache, and sequential versus random I/O http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/ Everything about MySQL Performance Tue, 02 Dec 2008 19:58:56 +0000 http://wordpress.org/?v=2.5.1 By: dbnewz » Blog Archive » Cardinalité, sélectivité et distributivité d’un index MySQL : quel impact sur le plan d’exécution ? http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-351928 dbnewz » Blog Archive » Cardinalité, sélectivité et distributivité d’un index MySQL : quel impact sur le plan d’exécution ? Thu, 04 Sep 2008 22:38:50 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-351928 [...] Une excellente illustration des difficultés parfois rencontrées par l’optimiseur, un coup de pouce du DBA permet alors de réduire la requête de 2.5 jours à 1h ! [...] [...] Une excellente illustration des difficultés parfois rencontrées par l’optimiseur, un coup de pouce du DBA permet alors de réduire la requête de 2.5 jours à 1h ! [...]

]]> By: Yasufumi Kinoshita http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-299242 Yasufumi Kinoshita Thu, 15 May 2008 05:55:40 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-299242 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. 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.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298520 Baron Schwartz Tue, 13 May 2008 22:00:27 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298520 Triffids, I don't know much about the multi-range read feature. (I say that about lots of things until I have studied it a lot). It's unfinished, and I would bet the final implementation will be somewhat different than it is now. Triffids, I don’t know much about the multi-range read feature. (I say that about lots of things until I have studied it a lot). It’s unfinished, and I would bet the final implementation will be somewhat different than it is now.

]]> By: Triffids http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298489 Triffids Tue, 13 May 2008 18:53:41 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298489 Cool feature ! and how MySQL optimizer chose random read (and read some blocks from cache) or use MRR (all blocks from HDD) ? Cool feature ! and how MySQL optimizer chose random read (and read some blocks from cache) or use MRR (all blocks from HDD) ?

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298472 Baron Schwartz Tue, 13 May 2008 16:58:48 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298472 Triffids, see http://www.mysqlperformanceblog.com/2008/03/25/mysql-60-vs-51-in-tpc-h-queries/ Triffids, see http://www.mysqlperformanceblog.com/2008/03/25/mysql-60-vs-51-in-tpc-h-queries/

]]> By: Triffids http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298459 Triffids Tue, 13 May 2008 16:15:55 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-298459 And why MySQL doesn't use scattered read (multiblock read) as it do rdbms leaders ? And why MySQL doesn’t use scattered read (multiblock read) as it do rdbms leaders ?

]]> By: Webadmin rövidhírek #2 at ‹Webakadémia /› http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-294116 Webadmin rövidhírek #2 at ‹Webakadémia /› Mon, 05 May 2008 07:35:57 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-294116 [...] 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 [...] [...] 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 [...]

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-291852 Baron Schwartz Fri, 02 May 2008 12:43:49 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-291852 Marki, to some extent that is true, but the effect isn't as severe as you think. Even in the worst case, if the scan is interrupted very often, it will still read many rows each time the disk services this task, and a full scan broken into thousands of pieces is still much faster than millions of random reads. Also, both the OS and the disk controller have a lot of intelligence to recognize and handle these scenarios (batching, reordering, read-ahead, etc), so they end up being more efficient than just random reads. Full scans for this type of query under a concurrent workload are still a big win. Marki, to some extent that is true, but the effect isn’t as severe as you think. Even in the worst case, if the scan is interrupted very often, it will still read many rows each time the disk services this task, and a full scan broken into thousands of pieces is still much faster than millions of random reads. Also, both the OS and the disk controller have a lot of intelligence to recognize and handle these scenarios (batching, reordering, read-ahead, etc), so they end up being more efficient than just random reads. Full scans for this type of query under a concurrent workload are still a big win.

]]> By: Marki http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-291685 Marki Fri, 02 May 2008 07:15:01 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-291685 Nice post. But is this still true when we have lot of different queries running in paralel? Won't they also use the disk and "interrupt" the sequential reads with their own reads and in fact the disk will be making random reads? If this is true, there is no reason in trying to optimize one particular query to use table scan (unless it is the only query running). Nice post. But is this still true when we have lot of different queries running in paralel? Won’t they also use the disk and “interrupt” the sequential reads with their own reads and in fact the disk will be making random reads? If this is true, there is no reason in trying to optimize one particular query to use table scan (unless it is the only query running).

]]> By: Clint Byrum http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-290666 Clint Byrum Wed, 30 Apr 2008 18:31:02 +0000 http://www.mysqlperformanceblog.com/2008/04/28/the-mysql-optimizer-the-os-cache-and-sequential-versus-random-io/#comment-290666 Yeah this is great stuff. I recall that MS SQL Server would actually figure out that a table and its indexes could fit into RAM, and load them into their equivilent of a memory engine temp table, allowing the optimizer to figure this stuff out. Seems like that would be a worthwhile feature for the query optimizer which would perform better than the underlying OS cache. Yeah this is great stuff. I recall that MS SQL Server would actually figure out that a table and its indexes could fit into RAM, and load them into their equivilent of a memory engine temp table, allowing the optimizer to figure this stuff out. Seems like that would be a worthwhile feature for the query optimizer which would perform better than the underlying OS cache.

]]>