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

[北村 英志]

北村です。


> >                      ->  Index Scan using fdata_feedid_idx on fdata fd  (cost=0.00..428326.23 rows=227837 width=20) (actual time=10.319..12576.345 rows=228140 loops=1)
> >                      ->  Sort  (cost=100002045.10..100002053.03 rows=3174 width=60) (actual time=466.426..4424.146 rows=2357243 loops=1)
> 
> ＃なぜここでものすごく行数が増えてしまっているのか理解に苦しむ・・・

確かに謎ですね。EXPLAINとANALYZEの結果でrowsが大幅に異なるものがまだ見ら
れますので、まだまだチューニングが必要なのでしょうか。


> >                            Sort Key: as.feed_id
> >                            ->  Hash Join  (cost=100000006.98..100001860.50 rows=3174 width=60) (actual time=0.911..306.691 rows=10573 loops=1)
> >                                  Hash Cond: ("outer".able_id = "inner".id)
> 
> ひょっとして、able_idとidは違う型だったりしますか？

どちらもintegerのようです。

ちなみに、ablesubのldata_idにINDEXを作っていたのですが、これをDROPするこ
とでさらに3秒ほど速くなったことを付け足しておきます。

> 岡野さん
> 細井さんのリプライをふまえると、他にも
> ・ディスクの読み書き回数が減ったか、統計情報(pg_statio_all_tables等)から判断
> ・ファイルサイズが減ったか、pg_classやpgstattuple関数やOS上のコマンドから判断
> などがあると思います。

VACUUM FULL前の状態を記録していなかったため、どの程度の効果があったかは
今から判断できないのですが、次に試す際は試してみたいと思います。


> 効果という点では、
> ・VACUUMでどれだけのレコードが消去できたかを、VERBOSEオプションで表示される内容から確認
> も忘れずにやらないといけないですね。

fdataテーブルは追加・更新は頻繁に行われますが、削除がほとんど行われない
ため、先ほど送ったEXPLAIN ANALYZEの結果では、効果が現れにくかったようで
す。
逆に、他のテーブルのログを見てみると、かなり消去できたようです。