Comments on: MySQL 6.0 vs 5.1 in TPC-H queries

By: MySQL 6 Further Reading | Butterfly Media Romania Blog - Marketing, SEO and WordPress

Tue, 05 Aug 2008 09:57:28 +0000

[...] MySQL 6.0 vs 5.1 in TPC-H queries If you had issues with subqueries in MySQL 4.1 or 5.0 and pulled away from using them I’d encourage you to try MySQL 6.0 and see if your issues are fixed or described in the documentation published. [...]

By: martin kersten

martin kersten — Mon, 14 Jul 2008 12:45:52 +0000

Is there a comprehensive list with the TPC-H performance figures for SF-1 until SF-100 for out of the box MySQL, or with all trickery of a DBA applied.

By: Piotr Kołaczkowski

Piotr Kołaczkowski — Sat, 21 Jun 2008 13:15:50 +0000

The main cost of executing wide index range scans is NOT the order of the blocks in the table. The main cost is that the blocks are in different places in the table, so even reading them in sequential order still requires to move the disk drive’s heads from place to place. As I first read about MRR and expectations this technique should provide the same speed advantage as clustered indexes, I laughed Actually MRR would help a little only because MySQL doesn’t take advantage from asynchronous I/O support (or am I wrong?). Having async I/O makes MRR useless, as the OS / disk drive’s firmware does block ordering itself.

By: TPC-H Run on MySQL 5.1 and 6.0 | MySQL Performance Blog

TPC-H Run on MySQL 5.1 and 6.0 | MySQL Performance Blog — Thu, 10 Apr 2008 22:22:28 +0000

[...] As you can see on 100G data set MySQL 5.1 could only complete 10 out of 22 queries within 3hours run time allowed for each query and MySQL 6.0 has similar number of queries it can execute in reasonable time frame. There 2 queries (Query8 and Query20) which MySQL 6.0 does better but there is also Query11 in which significant regression is observed. Vadim has already Wrote about it in his MySQL 5.1 vs 6.0 in TPC-H Queries post [...]

By: Vadim

Vadim — Wed, 09 Apr 2008 00:54:19 +0000

Noah,

I tried different scale factors 1, 10, 100.

I can’t say how MySQL scales because I have not done experiments.
Some queries even with scale factor 1 take hours to complete.

By: Noah

Noah — Wed, 09 Apr 2008 00:49:53 +0000

Hi Vadim,

- Which scale factor are you using?
- How MySQL 5.1/6.0 scales with TPC-H (e.g.: scale factors 1,3,5,10,30,100)?

Thanks,

Noah

By: Vadim

Vadim — Fri, 28 Mar 2008 16:19:51 +0000

Timour, I use dbgen utility from tpc-h benchmark to generate data. It produce data for lineitem as (first N rows from generated file): 1996-03-13|1|1551894|76910|1|17|33078.94|0.04|0.02|N|O|1996-02-12|1996-03-22|DELIVER IN PERSON|egular courts above the|TRUCK| 1996-04-12|1|673091|73092|2|36|38306.16|0.09|0.06|N|O|1996-02-28|1996-04-20|TAKE BACK RETURN|ly final dependencies: slyly bold | 1996-01-29|1|636998|36999|3|8|15479.68|0.10|0.02|N|O|1996-03-05|1996-01-31|TAKE BACK RETURN|riously. regular, express dep|REG AI 1996-04-21|1|21315|46316|4|28|34616.68|0.09|0.06|N|O|1996-03-30|1996-05-16|NONE|lites. fluffily even de|AIR| 1996-03-30|1|240267|15274|5|24|28974.00|0.10|0.04|N|O|1996-03-14|1996-04-01|NONE| pending foxes. slyly re|FOB| 1996-01-30|1|156345|6348|6|32|44842.88|0.07|0.02|N|O|1996-02-07|1996-02-03|DELIVER IN PERSON|arefully slyly ex|MAIL| 1997-01-28|2|1061698|11719|1|38|63066.32|0.00|0.05|N|O|1997-01-14|1997-02-02|TAKE BACK RETURN|ven requests. deposits breach a|RA 1994-02-02|3|42970|17971|1|45|86083.65|0.06|0.00|R|F|1994-01-04|1994-02-23|NONE|ongside of the furiously brave acco|AIR| 1993-11-09|3|190355|65359|2|49|70822.15|0.10|0.00|R|F|1993-12-20|1993-11-24|TAKE BACK RETURN| unusual accounts. eve|RAIL| 1994-01-16|3|1284483|34508|3|27|39620.34|0.06|0.07|A|F|1993-11-22|1994-01-23|DELIVER IN PERSON|nal foxes wake. |SHIP| 1993-12-04|3|293797|18800|4|2|3581.56|0.01|0.06|A|F|1994-01-07|1994-01-01|NONE|y. fluffily pending d|TRUCK| 1993-12-14|3|1830941|5996|5|28|52411.80|0.04|0.00|R|F|1994-01-10|1994-01-01|TAKE BACK RETURN|ages nag slyly pending|FOB| 1993-10-29|3|621426|96445|6|26|35032.14|0.10|0.02|A|F|1993-12-18|1993-11-04|TAKE BACK RETURN|ges sleep after the caref|RAIL| 1996-01-10|4|880347|55372|1|30|39819.00|0.03|0.08|N|O|1995-12-14|1996-01-18|DELIVER IN PERSON|- quickly regular packages sleep. 1994-10-31|5|1085693|85694|1|15|25179.60|0.02|0.04|R|F|1994-08-31|1994-11-20|NONE|ts wake furiously |AIR| 1994-10-16|5|1239268|39269|2|26|31387.20|0.07|0.08|R|F|1994-09-25|1994-10-19|NONE|sts use slyly quickly special instruc|FOB| 1994-08-08|5|375302|306|3|50|68864.50|0.08|0.03|A|F|1994-10-13|1994-08-26|DELIVER IN PERSON|eodolites. fluffily unusual|AIR| 1992-04-27|6|1396355|21369|1|37|53697.73|0.08|0.03|A|F|1992-05-15|1992-05-02|TAKE BACK RETURN|p furiously special foxes|TRUCK| 1996-05-07|7|1820519|95574|1|12|17273.04|0.07|0.03|N|O|1996-03-13|1996-06-03|TAKE BACK RETURN|ss pinto beans wake against th|FOB 1996-02-01|7|1452428|77443|2|9|12423.15|0.08|0.08|N|O|1996-03-02|1996-02-19|TAKE BACK RETURN|es. instructions|SHIP| 1996-01-15|7|947798|97817|3|46|84904.50|0.10|0.07|N|O|1996-03-27|1996-02-03|COLLECT COD| unusual reques|MAIL| 1996-03-21|7|1630721|30722|4|28|46245.92|0.03|0.04|N|O|1996-04-08|1996-04-20|NONE|. slyly special requests haggl|FOB| 1996-02-11|7|1518939|93985|5|38|74398.68|0.08|0.01|N|O|1996-02-24|1996-02-18|DELIVER IN PERSON|ns haggle carefully ironic deposi 1996-01-16|7|792502|17510|6|35|55806.45|0.06|0.03|N|O|1996-02-23|1996-01-22|TAKE BACK RETURN|jole. excuses wake carefully alongs 1996-02-10|7|1572371|22402|7|5|7216.50|0.04|0.02|N|O|1996-03-26|1996-02-13|NONE|ithely regula|FOB| and then I load it with LOAD DATA INFILE command. As you see data it ordered by columns (l_orderkey, l_lineitem). I can share generated files and LOAD DATA INFILE command, it takes about 8GB

By: Timour

Timour — Fri, 28 Mar 2008 12:37:01 +0000

Vadim,

Could it be possible that data on disk is already in the right physical order for this query? If the rows in lineitem are already ordered physically roughly in the same order as we would get by ordering the rowids we got via li_shp_dt_idx, then the overhead of MRR could be due to the unnecessary (in this case) rowid sorting.

Could you have a look at the script that populates lineitem and see whether that is the case?

By: Vadim

Vadim — Thu, 27 Mar 2008 22:40:49 +0000

Sergey,

Thank you for explain.
Also it is interesting why it does not give a lot of performance gain in case of cold caches.

By: Sergey Petrunia

Sergey Petrunia — Thu, 27 Mar 2008 21:42:34 +0000

Sure. The idea behind MRR (which stands for Multi Range Read) is to perform range scan as follows:
* Scan the index, collect the rowids in a buffer (of @@read_rnd_buff_size bytes)
* Sort the rowids
* Go and retrieve full table records in one sequential ’sweep’.

the expected improvement is that the full records are read sequentially which is faster than doing random disk probing. MRR doesn’t provide any speedup when all record data is in disk cache, but it was not expected to cause so much slowdown either.