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

[北村 英志]

谷田さん


> 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)
                                 ->  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は組み合わせないと効果が上がらないものでしょ
うか？
また、コストは相変わらず高いままなのですが、こういうものなのでしょうか？