Занятый стол не пылесосится

Мы используем 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

postgresql vacuum

— Барри
источник

См. Агрессивный автовакуум на PostgreSQL . Также было бы интересно иметь select * from pg_stat_user_tablesдля этой таблицы (используйте \xв psql для красиво отформатированного вывода)

— Daniel Vérité

Эта ссылка полезна и, возможно, отвечает на вопрос - таблица слишком занята для работы авто-пылесоса. @ DanielVérité Я обновил вопрос с выводом, который вы просили.

— Барри

Это много мертвых кортежей! Если возможно, рассмотрите возможность разбиения таблицы по меткам времени и удаления старых разделов вместо удаления. Главное предостережение в том, что уникальный индекс для разделов не поддерживается.

— Даниэль Верите

Есть ли в файле журнала сообщения об отмене автоочистки в этой таблице?

— Джанес

@jjanes Нет - в журналах не было указаний на то, что автовакуум когда-либо начинался.

— Барри

Я бы посмотрел на разделение . Если разделить по дням, вы можете просто удалить весь раздел, когда он станет слишком старым. Возможно, вам даже больше не придется пылесосить.

Кроме того, общая производительность может увеличиться, поскольку вы не вставляете туда, где вы удаляете. Вам просто нужно написать код для создания новых разделов и удаления старых.

Это именно то, для чего нужно разделение.

— SQB
источник