[pgsql-jp: 31981] Re: countが以上に遅い。

[TANIDA Yutaka]

谷田です。

On Tue, 13 Jan 2004 13:12:25 +0900
小野昇一 <ono ＠ searchina.ne.jp> wrote:

> ・以下explain analyzeの結果です。
> 	news=# EXPLAIN ANALYZE select count(*) from news_table ;
> 	NOTICE:  QUERY PLAN:
> 
> 	Aggregate  (cost=148292.30..148292.30 rows=1 width=0) (actual
> 	time=58467.49..58467.49 rows=1 loops=1)
> 	  ->  Seq Scan on news_table  (cost=0.00..148284.64 rows=3064 width=0) (actual time=56874.44..58198.89 rows=21239 loops=1)
> 	Total runtime: 58467.58 msec
> 	
> 	EXPLAIN

非常に大きなデータが大量に格納されているテーブルのようですね。一件平均
50kですか？これだけ大きいデータを格納していると、count(*)のような検索で
パフォーマンスを向上させるのは至難の業です。

もし、平均データ量がこんなに大きくないというなら、vacuum fullをする頃合
いではないかと思います。また、analyzeしているというにもかかわらずコスト
計算にひずみが出ている(rows=3064の予想に対してrows=21239の結果)ので、ひょっ
とすると"vacuum full analyze"で何らかの改善が見られるかもしれません。

テーブル定義を変更しても良いというのであれば、このテーブルから大きなデー
タのみを切り離すのが一番です。例えば、最初のテーブル定義のうちmessageだ
けが飛び抜けて大きいと仮定するなら、messageとuniqidを切り出して１テーブ
ルとし、messageが必要な場合だけJOINを使って取り出すという感じです。


-- 
TANIDA Yutaka <tanida ＠ sra.co.jp>