O VACUUM ANALYZE regular ainda é recomendado sob 9.1?

VACUUM só é necessário em linhas atualizadas ou excluídas em tabelas não temporárias. Obviamente você está fazendo muitos INSERTs, mas não é óbvio pela descrição que você também está fazendo muitos UPDATEs ou DELETEs.

Essas operações podem ser rastreadas com a pg_stat_all_tablesexibição, especificamente as colunas n_tup_upde . n_tup_delAlém disso, ainda mais importante, há uma n_dead_tupcoluna que informa, por tabela, quantas linhas precisam ser limpas. (consulte Monitorando estatísticas no documento para funções e visualizações relacionadas à coleta de estatísticas).

Uma estratégia possível no seu caso seria suprimir o VACUUM agendado, ficando de olho nessa view e verificando em quais tabelas ela n_dead_tupestá subindo significativamente. Em seguida, aplique o VACUUM agressivo apenas a essas tabelas. Isso será uma vitória se houver tabelas grandes cujas linhas nunca sejam excluídas nem atualizadas e o VACUUM agressivo for realmente necessário apenas em tabelas menores.

Mas continue executando o ANALYZE para que o otimizador tenha sempre estatísticas atualizadas.

Não vejo nada na sua pergunta que autovacuumnão resolva. Depende muito do padrão de suas atividades de escrita . Você menciona 3 milhões de novas linhas por semana, mas INSERT(ou COPY) normalmente não cria tabelas e índices inchados. ( autovacuumsó tem que cuidar das estatísticas da coluna , do mapa de visibilidade e de alguns trabalhos menores). UPDATEe DELETEsão a causa dominante do inchaço de tabelas e índices, especialmente ao segmentar linhas aleatórias. Não vejo nada disso na sua pergunta.

autovacuumpercorreu um longo caminho e está fazendo um ótimo trabalho no Postgres 9.1 ou posterior. Eu daria uma olhada nas autovacuumconfigurações . Se a aspiração tende a interferir com sua carga de trabalho, também dê uma olhada em "Atraso de vácuo baseado em custo" . A aspiração manual deve ser a rara exceção.

Se você tiver muitos s aleatórios UPDATE, talvez queira definir o FILLFACTORpara algo menor que 100, para permitir atualizações HOT imediatamente e reduzir a necessidade de VACUUM. Mais sobre atualizações HOT:

• Dados redundantes em declarações de atualização

Observe também que as tabelas temporárias precisam de manual VACUUM& ANALYZE. Cito o manual sobreCREATE TABLE :

O daemon de autovacuum não pode acessar e, portanto, não pode limpar ou analisar tabelas temporárias. Por esse motivo, as operações apropriadas de vácuo e análise devem ser executadas por meio de comandos SQL de sessão. Por exemplo, se uma tabela temporária for usada em consultas complexas, é aconselhável executá ANALYZE-la depois que ela for preenchida.

Embora eu concorde que é melhor usar os recursos automáticos em vez de executá-los em todo o banco de dados, na maioria dos casos é necessário o ajuste por tabela.

Não concordo muito com a escolha de design do postgres para unir vácuo e análise, já vi vários casos em que bancos de dados que fazem muita inserção/atualização, mas pouca exclusão, nunca são analisados ​​e começam a ter um desempenho ruim.

A solução é entrar nas tabelas que são muito usadas e estão sujeitas a grandes consultas e definir as configurações de análise automática dessas tabelas para algo em que elas sejam analisadas uma vez ou a cada dois dias.

Você pode acessar as configurações por tabela no gui na guia de vácuo automático e verá as configurações de análise que podem ser definidas independentemente do vácuo.

As configurações acabam na tabela de opções e podem ser vistas com a consulta

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

e um valor amostral de uma análise agressiva pode ser

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Para ver quando foi a última vez que suas tabelas foram analisadas automaticamente

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;