ビジーテーブルが掃除機にかけられていません

WindowsではPostgres 9.2を使用して低頻度の時系列データを保存しています。毎秒約2000行を毎秒24時間、週7日、ダウンタイムなしで挿入しています。あるDELETE日の固定数にテーブルの長さを保つためにテーブルの上におき、10分ほどにこれが実行されます。これはかなり安定した9億行になります。（興味のある方のために、SELECT、INSERT、DELETEすべてのパフォーマンスです）。

そのためDELETE、行を削除してもディスク領域は解放されません。そのためVACUUMに実行する必要があります。

私はしました照会pg_stat_user_tablesとVACUUM、これまで実行していないように見えます。

さまざまなドキュメントから理解できること（http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html）：

• 自動バキュームがオンになっているようで、他のテーブルで実行されています。
• auto-vacuumは実行されませんFULL。また、テーブルの排他ロックは必要ありません。

自動バキュームが実行されていない理由はありますか？これは純粋にテーブルが常にビジーであるためですか？

そして、この場合はVACUUM毎回実行する価値がありますDELETE（10分ごとに実行されます）？

編集：

以下のSOリンクからSQLを使用してクエリを実行します。

-[ RECORD 2 ]---+---------------------------
schemaname      | stats
relname         | statistic_values_by_sec
last_vacuum     |
last_autovacuum |
n_tup           |    932,315,264
dead_tup        |    940,727,818
av_threshold    |    186,463,103
expect_av       | *

生の出力：

-[ RECORD 3 ]-----+---------------------------
relid             | 501908
schemaname        | stats
relname           | statistic_values_by_sec
seq_scan          | 12
seq_tup_read      | 4526762064
idx_scan          | 29643
idx_tup_fetch     | 2544206912
n_tup_ins         | 1573896877
n_tup_upd         | 0
n_tup_del         | 941176496
n_tup_hot_upd     | 0
n_live_tup        | 688858417
n_dead_tup        | 940727818
last_vacuum       |
last_autovacuum   |
last_analyze      |
last_autoanalyze  | 2014-08-09 01:36:21.703+01
vacuum_count      | 0
autovacuum_count  | 0
analyze_count     | 0
autoanalyze_count | 69

パーティショニングを調べます。日ごとにパーティション分割する場合、古くなったパーティション全体を削除するだけで済みます。掃除機をかける必要はもうありません。

また、削除する場所に挿入しないため、全体的なパフォーマンスが向上する可能性があります。新しいパーティションを作成し、古いパーティションを削除するためのコードを書く必要があるだけです。

これがまさにパーティション分割の目的です。