Uma consulta ficou lenta quando a tabela cresceu. Rode EXPLAIN (ANALYZE, BUFFERS) com filtros representativos em um ambiente seguro para observar o plano executado. Compare o número estimado de linhas com as linhas observadas e veja quantas vezes cada operação se repetiu.

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM orders
WHERE customer_id = 42
ORDER BY created_at DESC
LIMIT 20;

Leia o volume de trabalho

Em um nó executado várias vezes, actual rows e actual time são médias por execução. Olhe loops para entender o trabalho acumulado. Os tempos de nós pais incluem trabalho dos filhos, portanto somar todos os tempos distorce o total.

Um Seq Scan pode ser razoável quando a consulta lê boa parte da tabela. Para esse exemplo, compare o plano antes e depois de testar um índice que comece por customer_id e considere created_at. Meça com dados e seletividade parecidos com os reais. EXPLAIN ANALYZE executa a instrução. Para uma escrita, comece com EXPLAIN sem ANALYZE se só precisa ver a estimativa.

Documentação de referência · Como esperar o PostgreSQL ficar pronto no Docker Compose

Cuidado com dados e custos do plano

EXPLAIN ANALYZE executa o comando para medir o plano. A consulta do exemplo é somente leitura, mas o cuidado é importante para UPDATE, DELETE e comandos com efeitos colaterais. Para inspecionar uma escrita, use uma transação de teste e faça rollback quando isso for seguro. EXPLAIN sem ANALYZE não executa, mas suas estimativas dependem das estatísticas disponíveis.

BUFFERS ajuda a distinguir leituras do cache compartilhado de leituras no armazenamento. Um grande número de buffers não prova sozinho que um índice falta; compare com linhas retornadas, seletividade, custo de manter o índice e consultas de escrita afetadas. O plano também pode mudar conforme os valores dos parâmetros. Para consultas preparadas, compare estimativas genéricas e específicas conforme o comportamento da versão do PostgreSQL.

Atualize estatísticas e meça de novo

As estimativas de cardinalidade dependem de estatísticas coletadas pelo banco. Depois de uma carga grande, verifique se elas representam os dados atuais. Um índice composto ajuda quando a ordem e a combinação dos filtros correspondem ao padrão consultado. Um índice usado para uma query de teste pequena pode não ser escolhido para uma tabela maior porque o otimizador calcula outro custo.

Compare o plano original com uma alteração por vez e mantenha dados representativos. Registre a consulta, os parâmetros, a configuração e a versão do banco. Para produção, prefira uma ferramenta de acompanhamento de consultas lentas que agregue eventos com cuidado; não copie valores sensíveis dos parâmetros para relatórios públicos.

Uma otimização precisa ser comparada sob condições equivalentes. Execute a consulta com parâmetros e volume semelhantes, observe cache frio e aquecido quando isso fizer diferença e não use um único tempo como garantia. Um plano com menos custo estimado pode ser mais lento no cenário real. Guarde o plano antes e depois da mudança e inclua o caso em que há poucos resultados e outro em que o filtro seleciona uma fração maior da tabela.