0

ネットワーク内のサーバーの統計を保存するシステムがあります。その後、ユーザーはすべてのデータを消費し、その成長を計画できます。したがって、時間、日、週、年などのデータをグラフにまとめることが重要です。

私はこのようなことをしようとしています:

select created_time / 60, count(*)
from pm_server_stat
group by (created_time / 60);

--with this index
CREATE INDEX pm_server_stat_created_time_60
  ON pm_server_stat
  USING btree
  ((created_time / 60));

これは私が得る説明です

"GroupAggregate  (cost=189822.36..213951.06 rows=1206435 width=8)"
"  Output: ((created_time / 60)), count(*)"
"  ->  Sort  (cost=189822.36..192838.45 rows=1206435 width=8)"
"        Output: created_time, ((created_time / 60))"
"        Sort Key: ((pm_server_stat.created_time / 60))"
"        ->  Seq Scan on public.pm_server_stat  (cost=0.00..34967.44 rows=1206435 width=8)"
"              Output: created_time, (created_time / 60)"

なぜこれが起こるのか誰か知っていますか？タイプが違うのではないでしょうか？

4

1 に答える 1

2

PostgreSQLには、9.1以前の「カバー」インデックスはありません。つまり、とにかく行にアクセスする必要があります。その場合は、行をスキャンすることもできます。それらは9.2に登場する予定です（試してみたい場合は現在ベータテスト中です）が、とにかくこれに十分賢いのかどうかはわかりません。

とにかく「配信されるファイルの総数」または「送信されるパケットの総数」が必要になると、機能しなくなります。

通常、この種の要約タスクには、stats_minute、stats_hour、stats_day、stats_weekなどの1つ以上の要約テーブルがあります。必要な数は、合計データサイズ/パフォーマンス要件によって異なります。簡単なcronジョブを使用して、要約を最新の状態に保ちます。データが「遅い」タイムスタンプで受信される場合は、わずかな遅延が必要になるか、再計算が必要になる場合があります。

次に、現在の時間の開始以降のすべての行の実際の合計を含む要約テーブルの和集合を作成できます。これにより、クエリするデータがはるかに少なくなり、必要なだけ高速になります。

于 2012-08-17T18:49:53.590 に答える