[pgsql-jp: 29567] Re: インデックスの利用について

[Tatsuo Ishii]

石井です．

> 椎名です。
> 
> 石井さん、ありがとうございます。

どういたしまして．

> > (1) contrib/pgstattupleを使う．正確かつ簡単にサイズを知ることができる
> >     が，実行のたびにテーブルを全スキャンするので，実運用中などで負荷が
> >     気になる場合はおすすめしません．
> 
> まだテストサーバですのでいろいろできます。
> こういったツールを使ったことがなくちょっと迷ってしまいました。
> 石井さんが作られたのですね。ドキュメントが日本語で助かりました。
> 
> 結果です。
> table_len          | 299851776
> tuple_count	       | 1046698
> tuple_len          | 290065120
> tuple_percent      | 96.74
> dead_tuple_count   | 0
> dead_tuple_len     | 0
> dead_tuple_percent | 0
> free_space         | 4723360
> free_percent       | 1.58
> 
> > (3) 最近VACUUMを実行した時点のサイズでよければ，以下の問い合わせでサイ
> >     ズを知ることができる．
> > 
> >     SELECT relpages FROM pg_class WHERE relname = 'table1';
> 
>  relpages
> ----------
>     36603

テーブルの大きさは36603ページです．これに対してeffective_cache_sizeが
10000位あると，このケースではインデックスを使って方が有利とオプティマ
イザが判断したわけですね．

> オプティマイザの動作にはルールベースとコストベースがあり
> PostgreSQLはコストベース。

はい．

> 今回のケースではプランナ用の統計情報の精度がデフォルトのままでは
> ダメで、さらにディスクキャッシュが小さすぎたので統計情報の精度を
> 上げてもダメだった。ということは、キャッシュが違うデータで埋まっ
> ていた場合、やはりインデックスは使われないということはないでしょ
> うか？

それはありません．というか，オプティマイザはキャッシュの埋まり具合いま
では見ていないということです．オプティマイザは単にeffective_cache_size 
分のバッファを全部このテーブルのアクセスのために使えるものとして計算の
ネタに使っているだけです．

> 小さなテーブルだと違うと思いますが、今回のようなサイズのテーブル
> だと、全件走査するよりも使える場合はインデックスを使った方が確実
> に早いように思いますので、たとえば特定のテーブルは必ずインデック
> スを使うような設定ができればいいなと考えています。

インデックスを使えばなんでも一概に速くなるとは言い切れません．それが言
いきれる位なら苦労してコストベースのオプティマイザを実装する必要なんか
なくなります．
--
Tatsuo Ishii