[pgsql-jp: 29951] Re: SET STATISTICS の統計情報の目標値決定指標

[sugita ＠ sra.co.jp]

  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 29949] Re: SET STATISTICS の統計情報の目標値決定指標
Date: Sat, 17 May 2003 23:36:14 +0900

;;; いつも大変お世話になっております。それとご返答ありがとうございます。

  こちらこそです。

;;; > 今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
;;; > ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
;;; > てです。
;;; 
;;; 変わったとしたらデータ量です。

  データ量のみが同じ分布傾向で増えたと仮定するならば、単純に考えて、2 倍になっ
たのならば、2 倍の数の bin にするというのはどうでしょう?

;;; 				  今まで発行していたSQLは
;;; select * from tbl_hoge where kubun='010101';
;;; のようなSQLを発行しており、kubunカラムには単一でIndexが付与されていますが
;;; Seq Scanが走ってしまう場合があります。
;;; 
;;; パターンを調べてみたところ・・・
;;; 
;;; 【Seq Scanが走るパターン】
;;; kubunで絞り込んでも、20万件以上ある場合
;;; 
;;; 【Index Scanが走るパターン】
;;; kubunで絞り込むと、2万件以下に絞り込める場合
;;; 
;;; まだまだ細かいパターンがあるのかと思いますが、上記のような結果となりました。

  他の要因がないとは言えないので、まずは、EXPLAIN ANALYZE の結果をみないと何と
も言えません。

;;; 検索しようとしているkubun値の割合が〜%以上の場合はSeq Scanになると
;;; かいう指標とかあるのでしょうか？

  単にぎっしり詰まっているとは限りませんので、75〜90% の範囲ではないでしょうか。
簡単な表で、実際にデータ入れて、データの更新や削除をすると確かめられます。削除
されているデータの分布の具合によっては、10% 程シーケンシャルスキャンの方が速く
ても、遅い方のインデックスキャンが実行される場合もあったりもします。10% 程度な
らば誤差の内です。


Kenji Sugita