Database Lounge Tokyo#1 ツイートまとめ

2016年7月27日に開催されたDatabase Lounge Tokyo#1 ツイートまとめです。
0
前へ 1 ・・ 3 4 ・・ 7 次へ
めるぽん.c @melponn

shared state、結構ネックになりそうに見えるけど大丈夫なのかな #dbltokyo

2016-07-27 20:59:05
ts4 @ts4th

PostgreSQL の設計はキレイで素性が良いのだというのが実感できた。MySQLユーザの観点で言わせていただくと、 MySQL はこういうキレイな図を描くのがたいへんむずかしい #dbltokyo

2016-07-27 21:01:04
めるぽん.c @melponn

メッセージキューが遅いので、各bgworker側でfilterしてやった方がいい #dbltokyo

2016-07-27 21:01:21
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_

仕事でワーカーのことを考え、仕事後もワーカーの話を聞いてる

2016-07-27 21:05:10
めるぽん.c @melponn

札幌側「全然わかんない!」発表者「おかしいなー今日はゆるふわな話のつもりだったんだけど」 #dbltokyo

2016-07-27 21:05:37
おさない @machico220

ディープです! ディープです!! #dbltokyo

2016-07-27 21:07:21
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
nhiroki @nhiroki_

肝心の並列クエリの話をちゃんと聞いてなかった・・・

2016-07-27 21:17:15
Kosuke Kida @kkkida_twtr

海外さんのPG-Stromとの組み合わせの紹介 #dbltokyo

2016-07-27 21:17:38
めるぽん.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
nhiroki @nhiroki_

並列クエリのコスト計算大変そうだ

2016-07-27 21:18:43
Kosuke Kida @kkkida_twtr

こうゆうパラレルを上手く扱えるようにオプティマイザが賢くなってる(パラレルでのコスト見積もりの精度をあげる) #dbltokyo

2016-07-27 21:19:25
nhiroki @nhiroki_

プロセス間通信のコストとかどうやって判断するんだろ

2016-07-27 21:20: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
めるぽん.c @melponn

SQLの中にCUDAロジックを書けるように拡張する…? #dbltokyo

2016-07-27 21:24:17
nhiroki @nhiroki_

ハッシュタグ付けてツイートするの忘れてた。プロセス間での状態共有の話が面白かったのと、マルチプロセスでのコスト計算の詳細が気になりました #dbltokyo

2016-07-27 21:28:11
前へ 1 ・・ 3 4 ・・ 7 次へ