Ми використовуємо Postgres 9.2 в Windows для зберігання даних із низькочастотними хронометражами: ми вставляємо близько 2000 рядків в секунду кожні другі 24 години 7 днів на тиждень без простоїв. Існує такий, DELETEякий працює на столі кожні 10 хвилин або близько того, щоб тримати стіл до фіксованої кількості днів. Це в кінцевому підсумку є досить стабільним 900 мільйонів рядів. (Для тих , хто зацікавлений, SELECT, INSERT, DELETEвсе продуктивний).
Таким чином DELETE, видалення рядків не звільняє місце на диску. Для цього нам потрібно VACUUMбігти.
Я запитував pg_stat_user_tablesі, VACUUMздається, ніколи не запускався.
Що я розумію з різних документів ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):
- у нас, здається, увімкнено автоматичне вакуумування, і він працює на інших таблицях.
- автоматичний вакуум не працює
FULLі не повинен вимагати ексклюзивного блокування на столі.
Хтось має думки, чому не працює автоматичний вакуум? Це виключно тому, що стіл постійно зайнятий?
І чи варто бігати VACUUMпісля кожного DELETEв цьому випадку (який працює кожні 10 хвилин)?
Редагувати:
Запит за допомогою SQL за посиланням SO нижче:
-[ 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
select * from pg_stat_user_tablesцю таблицю (використовуйте\xв psql для добре відформатованого виводу)