[pgsql-jp: 41474] Re: AutoCommitをfalseにするとレスポンスが遅くなる

[MauMau]

MauMauです。

> 遅い方の実行計画はプラン中に$1や$2などが見えますので、値がバインドされる前の 
> 
> 汎用的な実行計画に見えます。
> 早い方の実行計画は、実際にバインドされた値でもって作成された実行計画に見えます。

PostgreSQL 9.1までは、問い合わせ計画の作成時にはバインド変数の値は使われません。 

汎用的な問い合わせ計画が作成されます。
今回の場合、それがnested loopだったのでしょう。

PostgreSQL 9.2からは、次のように、バインド変数の値が使われるようになりました。 

そのため、9.2にアップグレードすることが解決方法の１つだと考えます。
可能であれば、おためしいただいた結果を共有いただけると幸いです。

http://www.postgresql.org/docs/current/static/release-9-2.html
Allow the planner to generate custom plans for specific parameter values 
even when using prepared statements (Tom Lane)
In the past, a prepared statement always had a single "generic" plan that 
was used for all parameter values, which was frequently much inferior to the 
plans used for non-prepared statements containing explicit constant values. 
Now, the planner attempts to generate custom plans for specific parameter 
values. A generic plan will only be used after custom plans have repeatedly 
proven to provide no benefit. This change should eliminate the performance 
penalties formerly seen from use of prepared statements (including 
non-dynamic statements in PL/pgSQL).


> なので、SQLの早い遅いは、実際のBIND値を考慮された実行計画かどうかの違いで、 
> 
> あとはそれがどこから来ているのか？ということか思います。

たしかに、速かったときは、バインド変数が使われなかったものと思います。
バインド変数が使われなかった理由はわかりません。
アプリなのか、JDBCドライバなのか、それともサーバ側なのか。
もしこれを追求する場合は、次の情報を共有してください。

・サーバ側が原因かどうか
サーバ側にバインド変数を含むSQL文が送られているかどうか、つまり、
SQL文中に$1などが含まれるかどうかを見ます。
auto_explainの出力か、log_min_duraton_statement=0で出力される
サーバログ中のSQL文でよいと思います。

・アプリかJDBCドライバか
テストアプリのソースを見せてください。


以上です。