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

北村 英志 ekitamura @ valueclick.jp
2004年 12月 1日 (水) 18:15:37 JST


皆様、色々とアドバイスを頂き、ありがとうございます。


・INDEX(feed_id, able_id等)について
	いずれも既にINDEXを張っていますが、使用されていないようです。こ
	のクエリーですと">"などが使用されているからでしょうか。
	#テーブルのプライマリキーのINDEXは、table_pkeyがあるので改めて作
	成する必要はないですよね?
	
・REINDEXを実行
	先ほど実際に試してみました。問題となっていたfdataテーブルと
	ablesubテーブルに実行したのですが、いずれの場合もコストに変化は
	ありませんでした。ただし、実行時間は約半分になったようです。(そ
	れでも16秒ですが・・・)

・DISTINCTについて
	試しにDISTINCTをはずしたクエリーでEXPLAINしてみたのですが、コス
	トが340になりました!ただし、EXPLAIN ANALYZEでは、延々10分経って
	も結果が返ってきません。

・ALTER TABLE ALTER SET STATISTIC
	これは全く知らないコマンドでした。調べて試してみたいと思います。

・VACUUM FULLについて
	DBを止めるには色々と準備がありますので、少し先の話になってしまう
	かと思いますが、いずれ試してみたいと思います。

・postgresql.conf設定について
	まだ勉強不足のため、各パラメータの詳細を理解してからいじりたいと
	思います。


On Wed, 01 Dec 2004 17:31:48 +0900
TANIDA Yutaka <tanida @ sra.co.jp> wrote:

> 谷田です。この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>





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