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

[TANIDA Yutaka]

谷田です。

On Thu, 02 Dec 2004 10:56:05 +0900
北村 英志 <ekitamura ＠ valueclick.jp> wrote:

> 谷田さん
> 
> 
> > set enable_seqscan to false;としてからexplainを取るとどうなりますか？
> 
> VACUUM FULL実施後の結果になってしまいますが、、、
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  Limit  (cost=100454781.10..100454788.88 rows=20 width=60) (actual time=26413.420..26413.479 rows=1 loops=1)
>    ->  Unique  (cost=100454781.10..100458484.08 rows=9520 width=60) (actual time=26413.415..26413.473 rows=1 loops=1)
>          ->  Sort  (cost=100454781.10..100455151.40 rows=148119 width=60) (actual time=26413.411..26413.429 rows=18 loops=1)
>                Sort Key: as.id, as.able_id, as.mem_id, as.feed_id, as.ldata_id, as.ts_fetch, as.ts_filter, as.ts_trigger, al."type"
>                ->  Merge Join  (cost=100002045.10..100436465.35 rows=148119 width=60) (actual time=19375.372..26412.777 rows=18 loops=1)
>                      Merge 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)))
>                      ->  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)

＃なぜここでものすごく行数が増えてしまっているのか理解に苦しむ・・・

>                            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は違う型だったりしますか？

>                                  ->  Seq Scan on ablesub as  (cost=100000000.00..100001547.52 rows=54852 width=52) (actual time=0.020..183.698 rows=33550 loops=1)
>                                  ->  Hash  (cost=6.96..6.96 rows=7 width=12) (actual time=0.608..0.608 rows=0 loops=1)
>                                        ->  Index Scan using able_pkey on able al  (cost=0.00..6.96 rows=7 width=12) (actual time=0.233..0.590 rows=1 loops=1)
>                                              Filter: ((status = 'OKAY'::bpchar) AND ("type" = 'MLST'::bpchar))
>  Total runtime: 26416.858 ms
> (17 rows)
> 
> 
> ところでその後、REINDEXをablesubテーブルに実施してみたのですが、10秒前後
> と、さらに速くなりました！
> やはりVACUUM FULL + REINDEXは組み合わせないと効果が上がらないものでしょ
> うか？

はい。

VACUUM FULLはテーブルのサイズ自体は減らすことができるのですが、実はINDEX
のゴミレコードを増やしてしまう欠点があるため、両方組み合わせることが有効
です。

> また、コストは相変わらず高いままなのですが、こういうものなのでしょうか？

コストはあくまで予測値であり、実際のスピードを表しているとは限りません。
どちらかというと、本当はコストに関係するパラメーターを調整して実測に沿っ
た値になるようにしなければならないぐらいです。実際にかかったコストは
actual timeのほうが正しいです。

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