Perícia de Queries no PostgreSQL (EXPLAIN, Bloat e Autovacuum)

Diagnostique lentidão no Postgres com EXPLAIN (ANALYZE, BUFFERS) e evidência de bloat e autovacuum.

Por Os Melhores Prompts

Categoria: Bancos de dados

O que ele faz

Lê o EXPLAIN (ANALYZE, BUFFERS) junto com pg_stat_user_tables, porque um plano ruim e um heap com bloat costumam ser o mesmo incidente. Encontra o nó em que linhas estimadas e reais divergem em uma ordem de grandeza, usa shared hit vs read para separar problema de CPU de problema de I/O, e então checa n_dead_tup, last_autovacuum e quem segura o xmin — transações longas, sessões idle in transaction, replication slots abandonados — antes de mexer em qualquer parâmetro de autovacuum. A saída é SQL executável com o nível de lock de cada ação.

Use quando

• Query que ficou lenta sem mudar código nem volume de dados
• Tabelas em que o autovacuum não acompanha mais a rotatividade
• Index-only scans que passaram a fazer heap fetches
• Escolher entre novo índice, REINDEX e tuning de autovacuum
• Postgres em RDS/Aurora onde VACUUM FULL não é uma opção

O que você recebe

• O nó dominante com razão de linhas e shared hit:read em números
• Classificação: estimativa ruim, bloat, spill de work_mem ou lock
• SQL executável: CREATE INDEX CONCURRENTLY, storage params, REINDEX
• A taxa estimada de bloat e o que de fato está segurando o xmin
• Como revalidar, buffers esperados e o que observar por 24 horas

Como usar

1. Rode a query como EXPLAIN (ANALYZE, BUFFERS) — sem BUFFERS não dá para separar cache miss de problema de CPU — e cole em {{query_and_plan}}.
2. Preencha {{table_stats}} a partir de pg_stat_user_tables: contagem de linhas, tamanho de tabela e índices, n_live_tup, n_dead_tup, last_autovacuum, last_analyze, idx_scan por índice e seq_scan.
3. Coloque scale factors, thresholds, autovacuum_max_workers, work_mem, shared_buffers, random_page_cost e effective_cache_size em {{autovacuum_settings}}, e versão, extensões e classe de instância em {{pg_version}}.
4. Em {{workload_context}}, informe a taxa de escrita, proporção update vs insert, sessões idle in transaction, replication slots, número de conexões e o pooler.
5. Aplique o SQL devolvido, refaça o plano e confirme a mudança em pg_stat_user_tables que prova que o vacuum recuperou o atraso.

Tags: postgres, postgresql, explain-analyze, autovacuum, bloat, indexing, query-tuning

Preço: 10.00 BRL