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

[shiina]

椎名です。

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

> なるほど．effective_cache_size = 10000 の場合，SET STATISTICS'の値が40
> で始めてインデックスが使われるようになったのですね．興味深い報告でした．

はい。そのとうりです。

テーブルの項目数は(キー項目以外は)かなり省略してありました。申し
訳ありません。

> (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

> pg_statisticの占める容量はたいしたものではないし，SET STATISTICSの値が
> 20から40に増えたところでANALYZEの負荷がさほど増えるとは思えないので，
> この例で言えばトレードオフと言うほどではないと思います．
> まあ，DB内の全テーブルのぜんぶのSET STATISTICSの値を増やせば影響がある
> と思いますが．

わかりました。

本格的にデータベースを扱うのが初めてで、見当違いをしているかもし
れません。ご指摘ください。

オプティマイザの動作にはルールベースとコストベースがあり
PostgreSQLはコストベース。
今回のケースではプランナ用の統計情報の精度がデフォルトのままでは
ダメで、さらにディスクキャッシュが小さすぎたので統計情報の精度を
上げてもダメだった。ということは、キャッシュが違うデータで埋まっ
ていた場合、やはりインデックスは使われないということはないでしょ
うか？
小さなテーブルだと違うと思いますが、今回のようなサイズのテーブル
だと、全件走査するよりも使える場合はインデックスを使った方が確実
に早いように思いますので、たとえば特定のテーブルは必ずインデック
スを使うような設定ができればいいなと考えています。