EDB Postgres Vision Tokyo 2018

ぬこ＠横浜 16.1 @nuko_yokohama

（この話、ラーメン店の常連に巧い対応の話にも聞こえるｗ）

ぬこ＠横浜 16.1 @nuko_yokohama

次はQuality Controlの話。 サービス業のQCの特徴。やり直しが不可能 プレゼンの仕方、プレゼン資料、服装・・・これらも品質の構成要素。

ぬこ＠横浜 16.1 @nuko_yokohama

プロセス型サービス：内容や結果を定義できる。 プロフェッショナルサービス：定義できない、顧客と一緒に決める。

ぬこ＠横浜 16.1 @nuko_yokohama

最後はOSS-DBなどの認定試験の広告。 なお、自分はOSS-DBの資格は失効済みｗ

ぬこ＠横浜 16.1 @nuko_yokohama

A会場へ移動にゃーん

ぬこ＠横浜 16.1 @nuko_yokohama

「野獣を解き放て – Postgres を更に速くする」 今日聞きたかった話だ！

ぬこ＠横浜 16.1 @nuko_yokohama

Auto-Failoverとzheapの話はしません。と最初に宣言。

ぬこ＠横浜 16.1 @nuko_yokohama

今日はパフォーマンスの話だけすると。 Analytics関係の改善。

ぬこ＠横浜 16.1 @nuko_yokohama

いきなり実行計画ベースの話ｗ

ぬこ＠横浜 16.1 @nuko_yokohama

9.6まではすべての条件式はツリーでシンプルに表現されていた。→これは遅い！

ぬこ＠横浜 16.1 @nuko_yokohama

10からはツリーではなく、仮想機械上で最適化してリニアに演算可能になった。 TPC-Hでのクエリでその改善効果を示している。

ぬこ＠横浜 16.1 @nuko_yokohama

Just In Time Compileの話きた！

ぬこ＠横浜 16.1 @nuko_yokohama

JITを使えば、特定のタイプで機能するように最適化できる？（この辺、何を言っているかよく理解できなかった）

ぬこ＠横浜 16.1 @nuko_yokohama

PG11：LLVMフレームワーク上でJITコンパイルを可能にした。

ぬこ＠横浜 16.1 @nuko_yokohama

TPC-H Q-01で効果を見れる。PG10から約半分のレイテンシに。

ぬこ＠横浜 16.1 @nuko_yokohama

JITの効果 OLTP：効果はあまりないようだ OLAP：効果はばつぐんだ

ぬこ＠横浜 16.1 @nuko_yokohama

@__munepom__ 効果のあった例示もTPC-Hだったので、集計や分析には強そうですね・・・・

munepom @__munepom__

@nuko_yokohama tpc.org/tpch/ 大規模データへのアドホッククエリ、なるほどですー

ぬこ＠横浜 16.1 @nuko_yokohama

jit_above_costパラメータ等のコスト定数でJITを使うかをプランナで判断する。

ぬこ＠横浜 16.1 @nuko_yokohama

クエリによってはJITを使うとプランニング時間含めて悪化する。

ぬこ＠横浜 16.1 @nuko_yokohama

JIT コンパイルのオーバーヘッドでトータルのクエリ実行時間が長くなるということもありうる。

ぬこ＠横浜 16.1 @nuko_yokohama

改善方法として、JITコンパイルとQuery実行を並列化するを考えている。

海外 浩平｜KaiGai Kohei🌻 @kkaigai

@nuko_yokohama OLAP系で特にCTEの山がいくつもあるようなクエリだと、ExecInitでJITコンパイルをキックして、実際の実行開始までにバイナリができてて嬉しいという事はしばしばあります。

ぬこ＠横浜 16.1 @nuko_yokohama

Executorの変更。これはOLTP/OLAPどちらにも効果がある。 ツリー構造トラバースの改善。Linearized Program化。 もう一つはAsync Execution。FDWなどの処理を並列化したい。