-
nuko_yokohama
- 5133
- 11
- 0
- 44
-
- いいね！44
ぬこ＠横浜 14.1
@nuko_yokohama
パーティションテーブル単位での並列処理はやらない。9.6だとパーティションプルーニングしないとつらぽよ #jpug_study
2017-01-21 14:30:01
fnwiya | wellday CPO
@fnwiya
postgresだとパーティショニングした場合に、起動済みのワーカーが各子表をみにいく #jpug_study
2017-01-21 14:32:29
ぬこ＠横浜 14.1
@nuko_yokohama
1.1億件と1400万件の表に対するJOINの例。大きいサイズのテーブルサイズによる並列処理をしてほしいのに、小さい表のサイズによる並列数でのスキャンがされちゃう件。 #jpug_study
2017-01-21 14:35:18
そーだい@初代ALF
@soudai1025
パラレルクエリ、100秒を10秒にするって感じの速度感なのでWebApplicationではなかなかメリットが出にくいところだよなぁ。 #jpug_study
2017-01-21 14:37:34
ぬこ＠横浜 14.1
@nuko_yokohama
gatherで集める量が多いと処理は遅くなる。EDB HINTも万能じゃない。 #jpug_study PostgreSQLのプランナはgatherが多くなるときには、並列スキャンを選択しないということかな？
2017-01-21 14:38:16
ぬこ＠横浜 14.1
@nuko_yokohama
ディスクソートからメモリソートにしたら、パラレルスキャンされなくなって、性能が悪くなるという事象。 #jpug_study EDB HINTを使うことでメモリソートしつつ、パラレルスキャンできるようになったと。
2017-01-21 14:42:18
ぬこ＠横浜 14.1
@nuko_yokohama
マテビューのリフレッシュ時にはパラレルスキャンはできない。 #jpug_study COPY, INSERT, CREATE TABLE ASに渡す、いずれも同様。
2017-01-21 14:45:11
そーだい@初代ALF
@soudai1025
結果が小さい場合は一旦psql経由でファイル出力してそれをCOPY文でINSERTって感じにすればパラレルクエリを利用した更新になる。 #jpug_study
2017-01-21 14:46:05
大山真実
@ooyamams1987
#jpug_study パラレルの課題の一つとして、実際に動かしてみないと何並列で処理されるかわからない、というのもあるのでは。
2017-01-21 14:48:14
Kazuki Higashiguchi
@hgsgtk
パラレルクエリ 使うのであれば、バッチ処理等になる。 パーティションとパラレルクエリを組み合わせて利用することは可能。 #PostgreSQL #jpug_study
2017-01-21 15:07:56
ぬこ＠横浜 14.1
@nuko_yokohama
@Mt_mo1019 DBT-3のようなモデルだと、それなりに効果出てるんじゃないのかなあ？ #jpug_study
2017-01-21 14:52:49
Iku
@Mt_mo1019
@nuko_yokohama それはその通りかもしれませんが、そもそもこう言うケースをアプリケーションで作ってはいけないと思うのです。大元の設計から見直す方が継続的に見て良い気がします。
2017-01-21 14:55:36
大山真実
@ooyamams1987
@nuko_yokohama @Mt_mo1019 P11からDBT-３の結果です。ご参考まで！ #jpug_study slideshare.net/masahikosawada…
2017-01-21 15:08:57
やっさん🍶
@yassan168
＃jpug_study パラレルクエリってサマリーしたでかいテーブルを分析用途でデータアナリストがゴリゴリSQLで分析する際には便利に使えそうなイメージ。なので、サービス向きには扱い難い気がする。
2017-01-21 14:59:12