Mesa ocupada não está sendo aspirada

Estamos usando o Postgres 9.2 no Windows para armazenar dados de séries temporais de baixa frequência: estamos inserindo cerca de 2000 linhas por segundo a cada segundo 24 horas, 7 dias por semana, sem tempo de inatividade. Existe um DELETEque é executado na tabela a cada 10 minutos, aproximadamente, para manter o comprimento da tabela em um número fixo de dias. Isso acaba sendo 900 milhões de linhas razoavelmente estáveis. (Para os interessados, SELECT, INSERT, DELETEestão todos performance).

Como tal DELETE, ao excluir linhas não está liberando espaço em disco. Para isso, precisamos VACUUMcorrer.

Tenho consultas pg_stat_user_tablese VACUUMparece que nunca foi executado.

O que eu entendo de vários documentos ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):

parece que o aspirador automático está ativado e está sendo executado em outras tabelas.
o vácuo automático não funciona FULLe não deve exigir um bloqueio exclusivo sobre a mesa.

Alguém tem alguma idéia de por que o aspirador automático não está funcionando? Isso é apenas porque a mesa está continuamente ocupada?

E vale a pena correr VACUUMdepois de tudo DELETEnesse caso (que é executado a cada 10 minutos)?

Editar:

Consulta usando o SQL no link SO abaixo:

-[ 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       | *

e produção bruta:

-[ 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

— Barry
fonte

Veja Autovacuum Agressivo no PostgreSQL . Também seria interessante ter select * from pg_stat_user_tablespara esta tabela (uso \xem psql para uma saída bem formatado)

— Daniel Vérité

Esse link é útil e talvez responda à pergunta - a tabela está muito ocupada para o aspirador automático funcionar. @ DanielVérité Atualizei a pergunta com a saída solicitada.

— Barry

São muitas tuplas mortas! Se possível, considere particionar a tabela com registro de data e hora e soltar as partições antigas em vez de excluir. A principal ressalva é que o índice exclusivo entre partições não é suportado.

— Daniel Vérité 14/08

O arquivo de log tem mensagens sobre o vácuo automático nesta tabela sendo cancelada?

— precisa saber é

@jjanes Não - não havia indicação nos logs de que o autovacuum foi iniciado.

— Barry

Eu procuraria particionar . Se particionado por dia, você pode simplesmente descartar a partição inteira assim que ela ficar muito antiga. Você pode até não precisar mais aspirar.

Além disso, o desempenho geral pode aumentar, pois você não está inserindo onde está excluindo. Você só precisa escrever o código para criar novas partições e excluir as antigas.

É exatamente para isso que serve o particionamento.

— SQB
fonte