This query plan doesn’t use a filesort so it shouldn’t generate a temporary table. It should scale pretty well as long as key_buffer_size is >= the size of the new composite index on the lineitem table. You can check the size of that index with the information schema.

Setting PACK_KEYS=1 on lineitem will probably result in even improved results as you will get compression on repeating integer key values in the composite key.

and then I analyzed both tables. Without any hints MySQL comes up with this:

mysql> explain
-> select sum(l_extendedprice) / 7.0 as avg_yearly
-> from lineitem , part
-> where p_partkey = l_partkey
-> and p_brand = ‘Brand#33′
-> and (p_container = ‘WRAP PACK’ )
-> and l_quantity < (
-> select 0.2 * avg(l_quantity)
-> from lineitem
-> where l_partkey = p_partkey
-> );
+—-+——————–+———-+——+—————————+————–+———+——————————+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+——————–+———-+——+—————————+————–+———+——————————+——+————-+
| 1 | PRIMARY | part | ref | PRIMARY,p_brand | p_brand | 20 | const,const | 157 | Using where |
| 1 | PRIMARY | lineitem | ref | lineitem_fk3,part_qty_idx | lineitem_fk3 | 4 | tpch1g_myisam.part.p_partkey | 2376 | Using where |
| 2 | DEPENDENT SUBQUERY | lineitem | ref | lineitem_fk3,part_qty_idx | lineitem_fk3 | 4 | tpch1g_myisam.part.p_partkey | 2376 | |
+—-+——————–+———-+——+—————————+————–+———+——————————+——+————-+
3 rows in set (0.00 sec)

mysql> select sum(l_extendedprice) / 7.0 as avg_yearly from lineitem , part where p_partkey = l_partkey and p_brand = ‘Brand#33′ and (p_container = ‘WRAP PACK’ ) and l_quantity < ( select 0.2 * avg(l_quantity) from lineitem where l_partkey = p_partkey );
+—————+
| avg_yearly |
+—————+
| 312967.325714 |
+—————+
1 row in set (0.23 sec)

I don’t have a SF10 myisam lying around, but you might want to give it a whirl if you do.

I take it this was SF1? Looks like you have about 6M rows in the fact table.

Cheers!

Jay

I spent some time on your recommendations, and ran enough experiments that I thought it would be worth another post. It should be up shortly.

Regarding the question of TPC-H rules for defining indexes – my point for the post was to show how clustering indexes can help, not how to get valid TPC-H performance measurement. “TPC-H-like” was used deliberately to avoid contending with the TPC rules. All good ideas are welcome here.

Dave

Cheers!

Jay

Thanks for the ideas. Will try them in the next couple days and let you know how it goes.

Dave

select
sum(li.l_extendedprice) / 7.0 as avg_yearly
from lineitem li
inner join part p
on li.l_partkey = p.p_partkey
inner join (
select l_partkey, 0.2 * avg(l_quantity) as quantity
from lineitem
group by l_partkey
) as quantities
on li.l_partkey = quantities.l_partkey
and li.quantity < quantities.quantity
where
p.p_brand = ‘Brand#33′
p.p_container = ‘WRAP PACK’;

and put an index on lineitem (l_partkey, l_quantity)

Not sure if TPC-H allows you to optimize the terrible (for MySQL) queries it produces, but the above would likely cut the performance by a factor of 100 or more..

I’d be interested to see what EXPLAIN comes up with for the above rewritten query + additional index.

Cheers,

Jay Pipes

Cheers,

Jay