[pgsql-jp: 40892] Re: auto_explainの実行計画について
nozawakz @ nttdata.co.jp
nozawakz @ nttdata.co.jp
2011年 8月 19日 (金) 20:56:31 JST
板垣様
ご回答いただき、ありがとうございました。
私の理解の仕方が間違えているのか
板垣様の試験の結果と乖離がある理由が分からないでおります。
PostgreSQL 8.3の新機能として、SRA社のHPにも記載があるので
VACUUM, ANALYZE, DDL変更時に関連するキャッシュを破棄し、
再プランニングを行うようになっているように見受けられます。
・テーブル定義の変更もしくは統計情報が更新された場合に、キャッシュされたクエリを自動的に再計画するようになった
キャッシュ無効化イベント(CacheInvalidate※)が呼ばれれば、
再プランニングを行うと理解しております。
※inval.c
CacheInvalidateHeapTuple
CacheInvalidateRelcache
CacheInvalidateRelcacheByTuple
CacheInvalidateRelcacheByRelid
Prepared Statement は実行計画をPostgresプロセスにキャッシュし、
パーサとプランナをスキップすると思いますので、
postgresql.confにおいて、
log_parser_stats = on
log_planner_stats = on
log_executor_stats = on
とし、
「PARSE ANALYSIS STATISTICS」⇒Prepared Statement時でキャッシュがある時は出力されない
「REWRITER STATISTICS」⇒Prepared Statement時でキャッシュがある時は出力されない
「PLANNER STATISTICS」⇒Prepared Statement時でキャッシュがある時は出力されない
「EXECUTOR STATISTICS」
「PARSER STATISTICS」⇒??
のログがどのような時に出るかを実験してみようと思います。
以上、よろしくお願い致します。
-----Original Message-----
From: pgsql-jp-bounces @ ml.postgresql.jp [mailto:pgsql-jp-bounces @ ml.postgresql.jp] On Behalf Of Itagaki Takahiro
Sent: Friday, August 19, 2011 2:18 PM
To: PostgreSQL Japanese Mailing List
Subject: [pgsql-jp: 40891] Re: auto_explainの実行計画について
2011/8/19 <nozawakz @ nttdata.co.jp>:
> >ただ、こちらについては ANALYZE で再プランニングされるかは疑問です。
> >確かに ALTER TABLE 等、テーブル構成が変化するケースでは
> >再プランニングされるのですが、8.3 以降であっても ANALYZE だけでは
> >されないような気がします。
>
> 当方の試験手順に問題があるためか
> 再プランニングされておりました。
参考までに、こちらで確認した手順も送ります。
下記の "VACUUM ANALYZE" の前後で、プラン p のコストが変わっていないのが
気になっています。もし再プランニングされるのならば、プラン p2 のように
変更した seq_page_cost の値が反映されるはずだと思うんですよね……。
postgres=# SELECT version();
version
-----------------------------------------------------------------------------------------------------------------
PostgreSQL 9.2devel on x86_64-unknown-linux-gnu, compiled by gcc
(GCC) 4.5.1 20100924 (Red Hat 4.5.1-4), 64-bit
(1 行)
postgres=# LOAD 'auto_explain';
LOAD
postgres=# SET auto_explain.log_min_duration = 0;
SET
postgres=# SET client_min_messages = LOG;
SET
postgres=# SET seq_page_cost = 1;
SET
postgres=# PREPARE p AS SELECT count(*) FROM pg_class;
PREPARE
postgres=# EXECUTE p;
LOG: duration: 0.122 ms plan:
Query Text: PREPARE p AS SELECT count(*) FROM pg_class;
Aggregate (cost=11.60..11.61 rows=1 width=0)
-> Seq Scan on pg_class (cost=0.00..10.88 rows=288 width=0)
count
-------
288
(1 行)
postgres=# SET seq_page_cost = 1000;
SET
postgres=# PREPARE p AS SELECT count(*) FROM pg_class;
ERROR: prepared statement "p" already exists
postgres=# EXECUTE p;
LOG: duration: 0.037 ms plan:
Query Text: PREPARE p AS SELECT count(*) FROM pg_class;
Aggregate (cost=11.60..11.61 rows=1 width=0)
-> Seq Scan on pg_class (cost=0.00..10.88 rows=288 width=0)
count
-------
288
(1 行)
postgres=# VACUUM ANALYZE;
PREPARE p2 AS SELECT count(*) FROM pg_class;
EXECUTE p2;
VACUUM
postgres=# PREPARE p AS SELECT count(*) FROM pg_class;
ERROR: prepared statement "p" already exists
postgres=# EXECUTE p;
LOG: duration: 0.035 ms plan:
Query Text: PREPARE p AS SELECT count(*) FROM pg_class;
Aggregate (cost=11.60..11.61 rows=1 width=0)
-> Seq Scan on pg_class (cost=0.00..10.88 rows=288 width=0)
count
-------
288
(1 行)
postgres=# PREPARE p2 AS SELECT count(*) FROM pg_class;
PREPARE
postgres=# EXECUTE p2;
LOG: duration: 0.044 ms plan:
Query Text: PREPARE p2 AS SELECT count(*) FROM pg_class;
Aggregate (cost=8003.60..8003.61 rows=1 width=0)
-> Seq Scan on pg_class (cost=0.00..8002.88 rows=288 width=0)
count
-------
288
(1 行)
--
Itagaki Takahiro
pgsql-jp メーリングリストの案内