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