2011年8月19日

[pgsql-jp: 40892] Re:auto_explainの実行計画について

板垣様

ご回答いただき、ありがとうございました。

私の理解の仕方が間違えているのか
板垣様の試験の結果と乖離がある理由が分からないでおります。


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@xxxxx [mailto:pgsql-jp-bounces@xxxxx] 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@xxxxx>:
> >ただ、こちらについては 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

投稿者 xml-rpc : 2011年8月19日 20:56
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/106241
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。