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

[TANIDA Yutaka]

谷田です。このSQLはもともとものすごく重いんじゃないかと思いますが・・・

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

> 谷田様
> 
> > explain analyzeの結果を見せて頂くことはできますか？
> 
> 少々見づらいと思いますが・・・
> 

>                ->  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)))
>                      ->  Seq Scan on fdata fd  (cost=0.00..27777.54 rows=227554 width=20) (actual time=0.006..25332.762 rows=227670 loops=1)

このseq scanが一番の問題ですね。fdataテーブルをvacuum fullしたり、
reindexすることで問題が解決しますか？あるいはfeed_idにインデックスを張っ
ていますか？

>                      ->  Hash  (cost=4511.81..4511.81 rows=1924 width=60) (actual time=558.671..558.671 rows=0 loops=1)
>                            ->  Hash Join  (cost=3.83..4511.81 rows=1924 width=60) (actual time=0.518..536.029 rows=10538 loops=1)
>                                  Hash Cond: ("outer".able_id = "inner".id)
>                                  ->  Seq Scan on ablesub as  (cost=0.00..4322.49 rows=33249 width=52) (actual time=0.007..357.254 rows=33279 loops=1)

ここも問題ではないかと思います。同様にablesubテーブルを処理できると思い
ます。あるいは、able,ablesubテーブルable_idやidカラムにindexを張ってます
か？

-- 
TANIDA Yutaka <tanida ＠ sra.co.jp>