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

[小野昇一]

小野です。

谷田 様　ご指摘のとおり vacuum full を実行して

以下を実行したところ、結果が大きく変わりました。

news=# EXPLAIN ANALYZE select count(*) from news_table ;
NOTICE:  QUERY PLAN:

Aggregate  (cost=3950.50..3950.50 rows=1 width=0) (actual time=213.25..213.25 rows=1 loops=1)
  ->  Seq Scan on news_table  (cost=0.00..3897.40 rows=21240 width=0) (actual time=0.07..189.70 rows=21243 loops=1)
Total runtime: 213.39 msec

EXPLAIN

やはり、週一回ぐらいはvaccum fullをしなければいけないですね。

どうもありがとうございました。

On Tue, 13 Jan 2004 13:32:51 +0900
TANIDA Yutaka <tanida ＠ sra.co.jp> wrote:

> 谷田です。
> 
〜〜省略〜〜
> 
> 非常に大きなデータが大量に格納されているテーブルのようですね。一件平均
> 50kですか？これだけ大きいデータを格納していると、count(*)のような検索で
> パフォーマンスを向上させるのは至難の業です。
> 
> もし、平均データ量がこんなに大きくないというなら、vacuum fullをする頃合
> いではないかと思います。また、analyzeしているというにもかかわらずコスト
> 計算にひずみが出ている(rows=3064の予想に対してrows=21239の結果)ので、ひょっ
> とすると"vacuum full analyze"で何らかの改善が見られるかもしれません。
> 
> テーブル定義を変更しても良いというのであれば、このテーブルから大きなデー
> タのみを切り離すのが一番です。例えば、最初のテーブル定義のうちmessageだ
> けが飛び抜けて大きいと仮定するなら、messageとuniqidを切り出して１テーブ
> ルとし、messageが必要な場合だけJOINを使って取り出すという感じです。
> 
> 
> -- 
> TANIDA Yutaka <tanida ＠ sra.co.jp>
>