[pgsql-jp: 37050] Re: SELECTの性能

[TANIDA Yutaka]

谷田です。

結論が出ているようですが補足を。

On Tue, 16 May 2006 16:19:04 +0900
河本陽一 <komoto.yoichi ＠ kcc.co.jp> wrote:

> 　ソートにはインデックスは使用されないという記述があったので作成して
> いませんでした。

b-treeなら使いますよ。ただこのケースでは駄目で、素の（テーブルから直の）
Seq ScanとSortの組み合わせだけに使えます。

> > (2)
> > また、sql実行前に、
> > 
> > set enable_seqscan to off;
> > 
> > とすることで、強制的にインデックススキャンにできませんか？
> 
> 　できました！！　圧倒的に早くなりました。
> 　EXPLAIN ANALYZEは以下のようになりました。
> 
>  Limit  (cost=2706.08..2706.83 rows=300 width=142) (actual time=100.935..137.584 rows=300 loops=1)
>    ->  Sort  (cost=2706.08..2707.40 rows=531 width=142) (actual time=100.858..113.818 rows=300 loops=1)
>          Sort Key: t1.f6
>          ->  Nested Loop  (cost=0.00..2682.04 rows=531 width=142) (actual time=0.237..72.676 rows=509 loops=1)
>                ->  Index Scan using t2_f2_idx on t2  (cost=0.00..8.64 rows=3 width=28) (actual time=0.056..0.188 rows=3 loops=1)
>                      Index Cond: (f2 = 'xxx'::text)
>                ->  Index Scan using t1_f1_idx on t1  (cost=0.00..888.82 rows=185 width=118) (actual time=0.052..7.679 rows=170 loops=3)
>                      Index Cond: (t1.f1 = "outer".f1)
>                      Filter: ((f3 = 0) AND (f4 = false) AND (f5 IS NOT NULL))
>  Total runtime: 150.326 ms

このような「Aのほうが実際は速いのにコストの関係でBが採用される」という問
題は、コスト見積もりのためのパラメーターが最適ではないことに起因すること
が多いです。

どのようなパラメーターが関係するかは以下をどうぞ。

http://www.postgresql.jp/document/pg742doc/html/runtime-config.html#RUNTIME-CONFIG-QUERY

ちなみに、私のお勧めとしては

random_page_cost 少なめ
cpu_tuple_cost 多め
effective_cache_size 実メモリ/8192/2

ぐらいです。

-- 
TANIDA Yutaka <tanida at sraoss.co.jp>