[pgsql-jp: 32974] Re: 問い合わせの速度低下

[Tatsuo Ishii]

石井です．

> > ところで，「どんどん遅くなる」では良く状況がわかりませんので，EXPLAIN
> > ANALYZEの結果を速いときと遅いときの両方で見せてもらえませんか？
> 
> 試したクエリ
> 
> SELECT  COUNT( * )
> FROM    T_RESULT
> WHERE   TIME_SMPL > '2004-05-16 09:00:00' AND
>         TIME_SMPL <= '2004-05-17 09:00:00' AND
>         CHECK_ID = 256 AND
>         CHECK_SUB = 0
> ;
> 
> 実行プラン
> 
>  Aggregate  (cost=656.84..656.84 rows=1 width=0)
>    ->  Index Scan using i_result_3 on t_result  (cost=0.00..656.43 rows=166
> width=0)
>          Index Cond: ((check_id = 256) AND (check_sub = 0) AND
>           (time_smpl > '2004-05-16 09:00:00'::timestamp without time zone)
> AND
>           (time_smpl <= '2004-05-17 09:00:00'::timestamp without time zone))
> 

EXPLAINではなく，EXPLAIN ANALYZEの結果が見たかったのですが．EXPLAIN
ANALYZEではオプティマイザの見積もりと実際の差異を見られるので，別の方
がフォローしていたように，統計情報の取得が適切かどうか，あるいはインデッ
クスのはりかたが適切かどうかの判断ができます．

> 昨日までは、VACUUMするとクエリの実行プランでのインデックスの使い方が
> 時々変化していたのですが、今日は落ち着いたようです。
> 今までは、TIME_SMPLだけのインデックスを使って、CHECK_IDやCHECK_SUBがFilterに
> なっていたりとか、逆にCHECK_IDとCHECK_SUBの複合インデックスを使って、
> TIME_SMPLがFilterになったりしていたので、パフォーマンスの変化はこれが原因
> だったのでしょうか。。

Filterになってしまうと非常に遅くなりますが，その回避方法はケースバイケー
スなので「遅いとき」のEXPLAIN ANALYZEの結果を見せていただけないと良く
分かりません．postgresql.confの設定も関係します．
--
Tatsuo Ishii