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

ITAGAKI Takahiro itagaki.takahiro @ lab.ntt.co.jp
2004年 12月 1日 (水) 18:45:35 JST


板垣です。

On Wed, 01 Dec 2004 16:54:54 +0900
北村 英志 <ekitamura @ valueclick.jp> wrote:

> 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を書き換えると、
強制的に特定のクエリプランを使わせることができる場合があります。


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

------------------------------------------------------------
板垣貴裕 <itagaki.takahiro @ lab.ntt.co.jp>




pgsql-jp メーリングリストの案内