[pgsql-jp: 36251] Re: インデックステーブルが使われない理由？

[ISHIDA Akio]

こんにちは。石田@苫小牧市です。

Sato_Kenichi wrote:
>>index tableのハッシュ値も同じのがいっぱい有るんでしょう
>>ね。
>>だからといって、index tableを使わないのは納得できません。
>>index tableが使われない理由をご存じの方、教えて下さい。
> 

indexがあるからといって、必ずしもindex scanが速いとは
限りません。理由はおそらく、

o 少なくても行を取り出すためにインデックスとテーブル
  本体の両方にアクセスする必要がある。
o seq scanでは単にテーブルの先頭から順に行を取り出せば
  良い為、1回のページアクセスで大量の行を取り出せるが、
  index scanの場合はテーブル内にちらばった行に対して
  アクセスしなければならない為、1回のページアクセスで
  取り出せる行数がとても少ない(可能性がある)。

といったところだと思います。
そのため、大量の行がヒットしそうな場合は、プランナは
seq scanを選択します。

このコストの見積りには、「データがどれだけバラついて
いるか」の他に、テーブル内での物理的な格納順がどれだけ
バラついているか、というのも計算の要因になっているようです。

こういったコストの予測するためには
データをサンプリングする必要があります。これがanalyzeです。
木村さんのケースでは、もしかしたら「東京都」ではseq scan
を選択するが「沖縄県」ならindex scanを選択する、という
可能性もあります。

さとうさんのご指摘のように、enable_seqscan = false
にして、実際にindex scanの方が速くなるかどうか確かめて
みるのも良いと思います。これでindex scanの方が速いようで
あれば、プランナの見積りがずれているということなので、
プランナに関するいくつかのパラメータをチューニング
するという選択肢もあります。

以下は、以前にユーザ会北海道支部で行なった勉強会の資料です。
ラフなまとめですが、ご参考になれば。
http://www.mono-space.net/doc/jpug_ezo0501/


> 
> 私も同じような経験があります。
> 
> 100万件くらい入っているテーブルを検索したら、やたら時間がかかるので、
> EXPLAIN してみたら Seq Scan になってました。
> (INDEXを作ったカラムで検索してるのに…)
> 
> 私の場合、postgresql.conf を編集して、
> 
>>enable_seqscan = false
> 
> にしたら、見違えるように速くなりました。
> 
> これだと Seq Scan のほうが速くなる場合でも、インデックスを使うようになる
> と思いますが、そういう場合はレコード件数が少ないなど無視できる程度だろう
> と思ってます。
> 
> 一度この設定で試してみてはいかがでしょう？
> 
> index tableが使われない理由は分かりません。
> できれば私も理由が知りたいです。(^^;
> 
> ※ サンプル数が少なすぎるのかな…？
> 
> ---
> 佐藤 研一
> E-Mail: satok-point ＠ mf.point.ne.jp
> 
> 
>