[pgsql-jp: 29056] VACUUMにて結合が変化する時について

辻 靖 yasushi_tsuji @ nifty.com
2003年 2月 14日 (金) 15:02:42 JST


いつも、お世話になっております。
辻と申します。

素人内容で申し訳ありませんが、
下記の結果にて悩んでおります。
出来れば助言等を頂けると幸いです。


HOGE_01_TBL と HOGE_02_TBL が存在しておりまして
両方とも同じ内容(フィールド、プライマリーキー、インデックス)
で、同じ様なデータ件数です。

VACUUM ANALYZE HOGE_01_TBL
VACUUM ANALYZE HOGE_02_TBL
を毎日行っております。


理由はともあれ HOGE_02_TBL を DROP しなければいけない状況になり
DROP 後、以前の内容を反映し再作成したのです。
(手順:COPY→DROP→CREATE TABLE→COPY→CREATE INDEX)


EXPLAINにて、似たような結果になって安心し、その日は帰宅。
(テーブルA・テーブルB共に、入れ子ループ結合にてインデックス参照)

朝、出社し検索が遅くなっている事に気がつき
再度、同じクエリーにて EXPLAIN してみると DROP した HOGE_02_TBL が
マージ結合からの順スキャンになっておりました。

どうやら、深夜に行われる VACUUM によるものでした。
(再度作成しなおして VACUUM 前と後の結果から)


--- EXPLAIN 結果 ---------------------------------
hogedb=# EXPLAIN SELECT HOGE_01_TBL.NAME FROM HOGE_01_TBL \
         INNER JOIN UGO_01_TBL ON UGO_01_TBL.CODE = HOGE_01_TBL.CODE \
         WHERE UGO_01_TBL.ID = 'A00001' GROUP BY HOGE_01_TBL.NAME;

NOTICE:  QUERY PLAN:

Group  (cost=4637.55..4641.04 rows=140 width=36)
  ->  Sort  (cost=4637.55..4637.55 rows=1397 width=36)
        ->  Nested Loop  (cost=0.00..4564.54 rows=1397 width=36)
              ->  Seq Scan on UGO_01_TBL  (cost=0.00..22.50 rows=10
width=12)
              ->  Index Scan using HOGE_01_IDX on HOGE_01_TBL
(cost=0.00..452.62 rows=127 width=24)

EXPLAIN


hogedb=# EXPLAIN SELECT HOGE_02_TBL.NAME FROM HOGE_02_TBL \
         INNER JOIN UGO_02_TBL ON UGO_02_TBL.CODE = HOGE_02_TBL.CODE \
         WHERE UGO_02_TBL.ID = 'B00001' GROUP BY HOGE_02_TBL.NAME;

NOTICE:  QUERY PLAN:

Group  (cost=29894.40..29898.15 rows=150 width=36)
  ->  Sort  (cost=29894.40..29894.40 rows=1499 width=36)
        ->  Merge Join  (cost=29627.90..29815.35 rows=1499 width=36)
              ->  Sort  (cost=22.67..22.67 rows=10 width=12)
                    ->  Seq Scan on UGO_02_TBL  (cost=0.00..22.50 rows=10
width=12)
              ->  Sort  (cost=29605.24..29605.24 rows=14986 width=24)
                    ->  Seq Scan on HOGE_02_TBL  (cost=0.00..28565.86
rows=14986 width=24)

EXPLAIN
--------------------------------------------------


■謎
よくわからないのが何故 VACUUM にて、このような結果になったのしょうか?
Nested Loop → Merge Join

VACUUM ANALYZE にて、これが最適と判断されたにしても、6倍程遅くなっておりま
すし…
何卒、素人にもわかるように説明して頂けないでしょうか?

enable_indexscan
enable_hashjoin
enable_mergejoin
enable_nestloop
enable_sort
enable_tidscan

などは指定しておりません。

対策の1つとして、上記の「問合せの実行方法を制御するスイッチ」にて
行えば宜しいんですよね?(自信がなくて…)

すみませんが、宜しく御願い致します。






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