PQ, In-Memory PQ, In-Memory Non PQを比較する

hammeroraのTPC-Hベンチマークの10回繰り返しを行いASH Viewerで結果をモニタリングした：

A,B　Parallel Query　(PQが得意なCOMPRESSモードで実行)
C,D In-Memory Parallel Query　(In-Memoryが得意なNOCOMPRESSモードで実行。ただしlineitemのみ）
E,F In-Memory Non Parallel Query　(同上)

それぞれ、同時1セッションと2セッションの結果だ。

TPC-Hの結果でも以下のように書いた：

Parallel Queryは同時2セッションが限界で、それ以上は安定した計測値が出ないし、時間も掛かり過ぎた

TPC-Hの結果でも以下のように書いた：

それから、
In-Memoryはスケーラビリティでは大勝です。
でも、メモリに収まるサイズだからです。。。

でも、よくよく考えてみると、当たり前だな、同時8セッションまではスケーラブルで、それ以上は動かなくなるんだろう。

そして、Parallel Queryは初めから限界ディスク転送量を出してしまうので「同時実行制御」の工夫が必要だということが、今回のテストを通じて理解できた。

とIn-Memory non Parallel Queryじゃダメなんだよ！の中で書いたけど、In-Memory (Non) PQにも同じことが言える。In-Memory PQにはQueueing制御があるのだけど、

8セッションからのキューイング管理は実装CPUのスレッド数から割り出されているのだろうけど、今回使用しているCore i7 860だと、管理が始まる8セッションは少し遅すぎるのではないかと感じる。
実際4セッションでCPUは振り切れている。「In-Memory Parallel Queryセッション数」

同時8セッションまで動かしてしまうと、全てが動かなくなるので、やはり、同時制御の工夫が大事だと思う。

最後に、
Parallel QueryはCOMPRESSが得意。
In-Memory PQはNOCOMPRESSが得意。だから、

ALTER TABLE lineitem MOVE PARTITION 今月 NOCOMPRESS;
ALTER TABLE lineitem MOVE PARTITION 2ヶ月前 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION 3ヶ月前 COMPRESS;
..
ALTER TABLE lineitem MOVE PARTITION 1年前 COMPRESS;

のように工夫する。