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