-
kkkida_twtr
- 2104
- 9
- 0
- 0
-
- いいね！0
ts4
@ts4th
PostgreSQL の設計はキレイで素性が良いのだというのが実感できた。MySQLユーザの観点で言わせていただくと、 MySQL はこういうキレイな図を描くのがたいへんむずかしい #dbltokyo
2016-07-27 21:01:04
nhiroki
@nhiroki_
シリアライズしたバックエンドの状態を共有メモリに配置、各ワーカプロセスはそれとハンドルを元に呼び出し元バックエンドの状態を再現して処理を実行
2016-07-27 21:01:26
Kosuke Kida
@kkkida_twtr
ワーカーがよんだ結果を集めるGatherについて。各ワーカーでWHERE句が効いて、ギャザーを少なくすることが性能メリットを得られる #dbltokyo
2016-07-27 21:01:43
めるぽん.c
@melponn
「Q.パラレルアグリゲータがあるのでは？」「A.パラレルアグリゲータ使えるならいいけど、そうじゃないクエリもあるので、その場合は死ぬ」 #dbltokyo
2016-07-27 21:02:49
nhiroki
@nhiroki_
@mizonokuchi あと、全く同じようにマップしてポインタを直接渡せるようにすると、マルチスレッドと同じ問題 (壊れたポインタを渡して別のプロセスのメモリ空間を壊せる) 的なことを言ってた
2016-07-27 21:09:35
めるぽん.c
@melponn
並列Nested-Loop、outer tableは各bgworkerは一部しかスキャンしないようになる。inner tableは普通のDBと同じように使われる。なのでinner tableがNULLになる可能性があるのは無理なのでうまいことやる必要がある。 #dbltokyo
2016-07-27 21:10:28
Kosuke Kida
@kkkida_twtr
gatherの前にJOINするのも可能だが、インナーJOINなら可能、アウターJOINだと状況によりプランナが判断する #dbltokyo
2016-07-27 21:11:01
Kosuke Kida
@kkkida_twtr
パラレルスキャン→集計→ギャザー sum()とかcount()なら集計後にギャザーしても矛盾しない #dbltokyo
2016-07-27 21:12:42
めるぽん.c
@melponn
並列クエリのクエリプランは結構長くなるが、8プロセスの設定で1億行のアグリゲーション作成に11秒。普通のクエリだとクエリプランは短くなるが77秒かかる。 #dbltokyo
2016-07-27 21:16:27
めるぽん.c
@melponn
8プロセスの設定だけど、クエリ実行例を見る限り Workers Planned が 7 だから7プロセスで実行してるように見える。7倍だから綺麗に伸びてる #dbltokyo
2016-07-27 21:17:40
EBIHARA Yuichiro / 海老原 雄一郎
@yebihara
PostgreSQLのパラレルクエリーは、ギャザラーがワーカーに「お前ら働け！」ではなく、「俺もやるからみんなも手伝って！」って感じだな。 #dbltokyo
2016-07-27 21:18:20
Kosuke Kida
@kkkida_twtr
こうゆうパラレルを上手く扱えるようにオプティマイザが賢くなってる（パラレルでのコスト見積もりの精度をあげる） #dbltokyo
2016-07-27 21:19:25
めるぽん.c
@melponn
v9.7以降、ソートをパーシャルアグリゲータでやる、Hash Join するときのハッシュテーブルをshared memoriに乗せる、投機的実行したりみたいなことをやったりとかいろいろあるらしい。 #dbltokyo
2016-07-27 21:22:36
Kosuke Kida
@kkkida_twtr
今後の展望 ・パラレルソート＋マージジョイン ・ハッシュテーブルの共有 ・パーティションの効率利用 ・非同期実行（返ってきた順に上に結果を渡す） ・賢いオプティマイザ #dbltokyo
2016-07-27 21:24:13
nhiroki
@nhiroki_
ハッシュタグ付けてツイートするの忘れてた。プロセス間での状態共有の話が面白かったのと、マルチプロセスでのコスト計算の詳細が気になりました #dbltokyo
2016-07-27 21:28:11