[pgsql-jp: 29949] Re: SET STATISTICS の統計情報の目標値決定指標
Iso, Toshitaka
toshitaka.iso @ hp.com
2003年 5月 17日 (土) 23:36:14 JST
杉田さん。
いつも大変お世話になっております。それとご返答ありがとうございます。
> 今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
> ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
> てです。
変わったとしたらデータ量です。今まで発行していたSQLは
select * from tbl_hoge where kubun='010101';
のようなSQLを発行しており、kubunカラムには単一でIndexが付与されていますが
Seq Scanが走ってしまう場合があります。
パターンを調べてみたところ・・・
【Seq Scanが走るパターン】
kubunで絞り込んでも、20万件以上ある場合
【Index Scanが走るパターン】
kubunで絞り込むと、2万件以下に絞り込める場合
まだまだ細かいパターンがあるのかと思いますが、上記のような結果となりました。
検索しようとしているkubun値の割合が〜%以上の場合はSeq Scanになると
かいう指標とかあるのでしょうか?
お忙しいところ申し訳ありません。
よろしければご教授ください。
以上です。
-----Original Message-----
From: sugita @ sra.co.jp [mailto:sugita @ sra.co.jp]
Sent: Saturday, May 17, 2003 8:48 PM
To: pgsql-jp @ ml.postgresql.jp
Subject: [pgsql-jp: 29948] Re: SET STATISTICS の統計情報の目標値決定指標
杉田です。
From: "Iso, Toshitaka" <toshitaka.iso @ hp.com>
Subject: [pgsql-jp: 29947] SET STATISTICS の統計情報の目標値決定指標
Date: Sat, 17 May 2003 19:20:58 +0900
;;; 2000万レコードのデータ件数のあるテーブルでSeqscanが
;;; 走ってしまい困っております。
今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
てです。
;;; ALTER TABLE テーブル名 ALTER COLUMN SET STATISTICS N;
これは、ひとつの手段ですが、どのように問題が発生したかが把握できないと、必ず
しも有効かどうかは決められません。
;;; でテーブル単位に統計目標値を変えようと思っているのですが、
;;; 何か指標等があるのでしょうか?(レコード件数やデータサイズによってなど・・・)
日付項目を文字列で保持した上にインデックスにするような設計上のバグの場合はそ
れなりの修正負担が必要です。データの分布のピークが分かれば bin の数をどれくら
いにすればよいか予想はできます。
;;; 今のところは全テーブルがデフォルトの10で稼動しており、これを変えてAnalyze
;;; をかけたいと考えております。
全部の bin を細分化する必要はないはずで、特定のテーブルが対象となると思えま
す。
;;; また、変えたことによるリスク等があればお教えいただけたら幸いです。
bin の数が増える分の負荷は増えます。
Kenji Sugita
pgsql-jp メーリングリストの案内