[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 メーリングリストの案内