Quanto um ANALYZE VERBOSE pode ajudar em um PostgreSQL degradado?

Em um PostgreSQL degradado, ANALYZE VERBOSE costuma aparecer como uma ação relativamente simples: atualizar estatísticas e deixar o planner trabalhar com uma fotografia mais recente dos dados.

O problema começa quando essa ação vira uma explicação completa do incidente.

Em uma investigação real, ANALYZE VERBOSE foi executado em tabelas relevantes depois da coleta de sessões, waits, dead tuples e estatísticas. Após a execução, campos ligados a modificações desde o último analyze foram reduzidos e as estatísticas passaram a refletir a nova coleta.

Isso prova que o ANALYZE fez seu trabalho.

Não prova que ele era a causa raiz da degradação.

O que `ANALYZE` faz #

O PostgreSQL usa estatísticas para estimar cardinalidade e escolher planos.

Quando os dados mudam muito desde a última coleta, estimativas antigas podem contribuir para planos ruins.

A execução manual pode ser:

1
ANALYZE nome_da_tabela;

ou:

1
ANALYZE VERBOSE nome_da_tabela;

O VERBOSE adiciona informação sobre o trabalho executado; não muda a finalidade principal da operação.

Antes de executar, registre o estado #

Uma coleta útil:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
SELECT
  relname,
  n_live_tup,
  n_dead_tup,
  n_mod_since_analyze,
  last_analyze,
  last_autoanalyze,
  last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_mod_since_analyze DESC;

Isso ajuda a responder:

1
2
3
4
qual tabela mudou mais?
quando foi analisada pela última vez?
autoanalyze está acontecendo?
há volume relevante de dead tuples?

Sem essa fotografia, depois é difícil demonstrar o que realmente mudou.

`n_mod_since_analyze` é uma pista, não um SLA universal #

Esse campo ajuda a mostrar quantas modificações foram registradas desde a última análise estatística.

Um valor alto pode justificar investigação.

Mas não existe um número universal em que:

1
n_mod_since_analyze > X → banco degradado

A relevância depende do tamanho da tabela, distribuição dos dados, consultas e thresholds do autovacuum/autoanalyze.

Depois do ANALYZE, valide o que mudou #

Repita a mesma consulta:

1
2
3
4
5
6
7
8
9
SELECT
  relname,
  n_live_tup,
  n_dead_tup,
  n_mod_since_analyze,
  last_analyze,
  last_autoanalyze
FROM pg_stat_user_tables
ORDER BY relname;

O esperado é observar timestamp atualizado e queda nas modificações pendentes de análise para as tabelas processadas.

Essa é a evidência direta do efeito da ação.

O que não muda automaticamente #

ANALYZE não:

cria índice;
remove query duplicada da aplicação;
aumenta IOPS;
corrige lock;
reduz conexão excessiva por si só;
elimina dead tuples como um VACUUM faria;
resolve falta de memória;
prova que um plano anterior estava errado.

É comum executar ANALYZE, observar melhora e atribuir todo o incidente à estatística desatualizada. Isso pode ser verdade, mas precisa ser demonstrado.

Para falar em causalidade, compare plano e comportamento #

Quando for seguro, uma comparação útil é:

1
2
EXPLAIN (ANALYZE, BUFFERS)
SELECT ...;

antes e depois da atualização de estatísticas.

Em produção, atenção: EXPLAIN ANALYZE executa a consulta real.

Quando isso não for aceitável, use apenas:

1
2
EXPLAIN
SELECT ...;

E preserve os planos para comparação.

Correlacione com waits #

No caso que originou esta pauta, a investigação também tinha consultas esperando eventos como DataFileRead e BufferIO.

Isso significa que a análise não poderia parar no planner.

Era necessário correlacionar:

1
2
3
4
5
6
7
estatísticas
plano
I/O
concorrência
queries ativas
dead tuples
estado do host

Um banco pode ter estatísticas recém-atualizadas e ainda estar limitado por storage ou por workload concorrente.

`ANALYZE VERBOSE` é útil por ser observável #

A saída verbose ajuda a documentar quais relações foram efetivamente processadas.

Em um procedimento operacional, eu salvaria:

1
2
3
4
5
6
hora de início
lista de tabelas
saída do comando
duração
estatísticas antes/depois
estado das queries antes/depois

Assim a ação deixa de ser “rodei analyze e parece melhor”.

Quando eu consideraria executar manualmente #

Faz sentido investigar um ANALYZE manual quando:

houve carga ou importação relevante;
tabela mudou muito desde a última coleta;
last_autoanalyze está antigo ou ausente;
plano parece incoerente com a cardinalidade real;
autovacuum/autoanalyze pode não estar acompanhando;
existe janela operacional para executar e medir.

A ação deve ser dirigida às tabelas relevantes, não um ritual genérico em toda a base sem necessidade.

O que a fonte deste artigo sustenta #

A coleta operacional recuperada registra uma investigação PostgreSQL com estatísticas de tabelas, dead tuples, atividade e waits, seguida de ANALYZE VERBOSE em relações selecionadas e nova verificação das estatísticas.

O texto não afirma que ANALYZE resolveu sozinho o incidente nem transforma correlação temporal em RCA.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[ ] coletar pg_stat_user_tables antes
[ ] registrar last_analyze/last_autoanalyze
[ ] identificar tabelas realmente relevantes
[ ] preservar planos quando possível
[ ] executar ANALYZE em escopo controlado
[ ] salvar saída VERBOSE
[ ] repetir estatísticas
[ ] comparar queries/waits
[ ] medir resultado
[ ] não declarar RCA sem evidência adicional

O principal aprendizado #

ANALYZE VERBOSE pode ser uma ação importante em um banco degradado, mas seu valor aumenta quando ele é tratado como mudança mensurável dentro de uma investigação, não como botão de correção genérico.

Atualizar estatísticas é fato. Explicar o incidente exige mais evidência.

O que ANALYZE faz #