[pgsql-jp: 34394] Re: パフォーマンスチューニング

[北村 英志]

板垣さん

> > Hash Join  (cost=4516.62..50155.60 rows=99462 width=60) (actual time=6313.877..35382.972 rows=18 loops=1)
> >   Hash Cond: ("outer".feed_id = "inner".feed_id)
> >   Join Filter: ((("inner".ldata_id IS NULL) OR ("outer".id > "inner".ldata_id)) AND (("outer".ts_inst >= "inner".ts_fetch) OR ("outer".id > "inner".ldata_id)))
> 
> この部分の条件が複雑すぎて、適切なクエリプランを使ってもらえていないように思います。
> 行数の見積もりも大きく食い違っていますし。(rows=99462 vs. 18)

おお、こういう見方をするのですね！知らなかったです。。。


> 元々のSQLだと、この部分ですね。
> 	((as.ldata_id ISNULL AND fd.ts_inst>=as.ts_fetch) OR fd.id>as.ldata_id)
> ANALYZE をしても変わらないようならば、
> 手探りで効率の良いクエリプランを探すのも良いかもしれません。
> サブクエリ, IN, EXISTS などを使ってSQLを書き換えると、
> 強制的に特定のクエリプランを使わせることができる場合があります。

SQL自体まだまだ経験が浅いので、どう改善できるか分かりませんが、試行錯誤してみます。


> また、autovacuum を使っていらっしゃるようですが、
> autovacuum は「ある条件を満たした場合に」VACUUMを発行するプロセスです。
> 本当にその条件が満たされてVACUUMを発行されているか、もう一度確認していただけますか？
> デフォルトのパラメータで使っていると、意外にVACUUMされていないと思いますよ……。

これはpostgresql.confを見ればいいのでしょうか。
ログには実行の記録しか出ていないため、詳細は分かりません。ANALYZEはされ
ているようですが。

その後、いろんなテーブルをREINDEXしていたのですが、やはり大幅にスピード
がアップしているようです。EXPLAINコマンドで返ってくるコストは必ずしも下
がっているわけではなさそうですが、応答時間はかなり短くなっています。
やはりVACUUM FULL + REINDEXこそが捜し求めていた回答であり、効果アリ、と
言ってよさそうですね。
行数が増えれば、もっとシビアにクエリーや設計、設定を見直す必要があるとは
思われますが、当面はこれをcronにすることでなんとかなりそうです。

この件に関してはかなり長いこと悩んでいたので、今回ここで相談させていただ
いて本当に良かったです。パフォーマンスの向上については、引き続き相談させ
てください。

ひとまず、当初の悩みはおかげさまで解決されたということをお伝えいたします。
ありがとうございました。