Como identificar consultas lentas no PostgreSQL com EXPLAIN ANALYZE

A otimização de consultas no PostgreSQL não é apenas uma etapa técnica, é parte fundamental para qualquer aplicação que dependa de performance e estabilidade. Quando o banco começa a responder devagar, não adianta apenas criar índices aleatoriamente ou sair ajustando parâmetros. É preciso entender como o PostgreSQL pensa, como ele escolhe o plano de execução e por que certas consultas se tornam gargalos enquanto outras passam despercebidas. Neste conteúdo, a ideia é ir direto ao ponto, mostrando de forma prática como identificar, medir e resolver problemas de performance usando ferramentas internas do próprio banco. O objetivo é te dar clareza para diagnosticar consultas lentas de verdade, entender o motivo delas estarem demorando e, a partir disso, aplicar otimizações que realmente fazem diferença no dia a dia.

Por que consultas ficam lentas no PostgreSQL?

Quando uma consulta começa a demorar no PostgreSQL, a causa quase nunca é um único fator. Geralmente é um conjunto de escolhas ruins, falta de manutenção ou um crescimento de dados que não foi acompanhado por ajustes na estrutura. Entender o motivo do problema é essencial para otimizar de verdade, porque tentar acertar no escuro só gera retrabalho e mudanças que não resolvem a raiz da lentidão. A seguir, cada ponto crítico que costuma impactar o desempenho.

Problemas no plano de execução

O PostgreSQL sempre monta um plano antes de executar a query. Se o plano for ruim, o desempenho cai mesmo que a consulta esteja escrita corretamente. Às vezes o banco decide fazer um Seq Scan em vez de usar um índice, ou escolhe um JOIN ineficiente porque acredita que o número de linhas será pequeno. Isso acontece quando o planner toma decisões baseadas em estimativas incorretas. Um exemplo simples é quando um filtro deveria usar índice, mas o banco prefere ler a tabela inteira:

EXPLAIN ANALYZE
SELECT id, nome
FROM usuarios
WHERE ativo = true;

Se o plano mostrar um Seq Scan em uma tabela grande, já é um sinal de que o planner não está enxergando o cenário corretamente.

Falta de estatísticas atualizadas

As estatísticas alimentam todas as decisões do planner, e quando elas estão desatualizadas, o PostgreSQL calcula estimativas erradas. Isso resulta em escolhas ruins, como usar o índice errado ou subestimar o número de linhas retornadas. Tabelas que sofrem muitas inserções, atualizações ou exclusões costumam perder precisão rapidamente. Em muitos cenários, apenas rodar:

ANALYZE usuarios;

já melhora o plano de execução. Se o autovacuum estiver desativado ou mal configurado, esse problema se torna ainda mais frequente.

Falta de memória ou configuração inadequada

Mesmo com queries bem escritas e índices corretos, uma configuração ruim pode travar o banco. Quando o PostgreSQL não tem memória suficiente para fazer operações como SORT e HASH, ele começa a usar disco, o que deixa tudo mais lento. Um exemplo comum é o sort que vai para disco por falta de work_mem:

EXPLAIN ANALYZE
SELECT *
FROM vendas
ORDER BY data_venda;

Se o plano indicar que foi criado arquivo temporário, é sinal de pouca memória disponível para essa operação. Ajustes como aumentar work_mem para consultas específicas podem resolver:

SET work_mem = '256MB';

Queries mal escritas (JOINs, filtros, funções)

Consultas podem ficar lentas simplesmente porque foram mal estruturadas. JOINs sem condições adequadas, funções aplicadas em colunas filtradas, filtros pouco seletivos e subqueries desnecessárias são causas comuns. Por exemplo, filtrar usando função na coluna impede o uso do índice:

SELECT *
FROM pedidos
WHERE DATE(data_criacao) = '2024-01-10';

Esse tipo de filtro força um Seq Scan. A forma correta seria:

SELECT *
FROM pedidos
WHERE data_criacao >= '2024-01-10'
  AND data_criacao < '2024-01-11';

Agora o índice pode ser utilizado e a consulta fica muito mais rápida.

Alto volume de dados sem otimização

Quando a tabela cresce, o que funcionava antes deixa de funcionar. Índices começam a perder eficiência, consultas que faziam JOIN em poucas linhas passam a trabalhar com milhões e operações de ordenação e agregação ficam mais pesadas. Sem otimização contínua, o banco simplesmente não acompanha o ritmo. Um exemplo é uma consulta que faz agregação em uma tabela que aumentou demais:

SELECT categoria, COUNT(*)
FROM produtos
GROUP BY categoria;

O desempenho pode degradar ao longo do tempo se não houver índice adequado, particionamento ou ajustes no armazenamento.

À medida que os dados aumentam, o custo das operações cresce, e o banco exige mudanças estruturais para manter a performance. Analisar o plano, observar estatísticas, revisar índices e ajustar configurações passa a ser parte da rotina. Isso evita que o banco chegue no limite e permite manter a aplicação rápida mesmo com grande volume de dados.

Como identificar consultas lentas usando EXPLAIN e EXPLAIN ANALYZE

Quando uma query começa a demorar mais do que deveria, a melhor forma de entender o que está acontecendo é olhar o plano de execução. O PostgreSQL entrega duas ferramentas essenciais para isso: EXPLAIN e EXPLAIN ANALYZE. Saber a diferença entre elas e entender como interpretar o plano é o primeiro passo para descobrir gargalos de performance.

Diferença entre EXPLAIN e EXPLAIN ANALYZE

O EXPLAIN mostra o plano estimado do PostgreSQL. Ele revela como o banco imagina que vai executar a consulta, quais índices pretende usar e quais passos serão necessários. É útil para entender a estratégia que o otimizador escolheu, mas não mostra o tempo real de execução.

Já o EXPLAIN ANALYZE executa a query de fato e registra o que realmente aconteceu. Além da estratégia, você vê o tempo real gasto em cada etapa, a quantidade real de linhas processadas e se a estimativa do otimizador bate com a realidade. Se você precisa descobrir onde está o problema, o ANALYZE é sempre o diagnóstico mais preciso.

-- Apenas estimativa
EXPLAIN SELECT * FROM users WHERE email = '[email protected]';

-- Execução real com métricas
EXPLAIN ANALYZE SELECT * FROM users WHERE email = '[email protected]';

Como interpretar os principais elementos do plano

Quando o PostgreSQL imprime o plano, várias informações aparecem. Algumas delas são fundamentais para entender onde está o gargalo.

Seq Scan
Indica que o banco leu a tabela inteira linha por linha. Pode ser normal em tabelas pequenas, mas se a tabela tem milhões de registros e você esperava um índice, esse já é um sinal claro de problema.

Seq Scan on users  (cost=0.00..1200.00 rows=50000 width=120)

Index Scan
Aqui o PostgreSQL usou um índice para encontrar as linhas necessárias. Em geral é muito mais rápido que um Seq Scan, especialmente em filtros seletivos.

Index Scan using users_email_index on users  (cost=0.43..8.50 rows=1 width=120)

Sort / Hash
Sorts aparecem quando o banco precisa ordenar os dados e não pode usar um índice para isso. Hash aparece em operações de junção ou agregação. Sorts grandes e hashes que não cabem na memória acabam caindo em disco, o que derruba a performance.

Sort  (cost=2000..2100 rows=4000 width=120)
Hash Join  (cost=3000..5000 rows=10000 width=200)

Cost / Rows / Width
O cost é uma estimativa de esforço, não de tempo real. Cost baixo em cascata geralmente é bom. Rows mostra quantas linhas o PostgreSQL acha que vai processar. Width é o tamanho médio de cada linha. Quando as estimativas de Rows estão muito fora da realidade, o plano vai para caminhos ruins.

(cost=0.43..8.50 rows=1 width=120)

Node Type
Cada etapa do plano é um nó. Pode ser um Seq Scan, Index Scan, Hash Join, Nested Loop e por aí vai. A análise dos nós em cascata mostra exatamente a sequência de operações executadas.

Exemplo real de diagnóstico de uma query lenta

Imagine a seguinte consulta:

SELECT p.*
FROM products p
JOIN categories c ON c.id = p.category_id
WHERE c.slug = 'smartphones'
AND p.price > 2000;

Agora o EXPLAIN ANALYZE revela o problema:

Seq Scan on categories c
  Filter: (slug = 'smartphones')

Nested Loop
  -> Seq Scan on products p
       Filter: (price > 2000)
  -> Hash Join

Aqui já vemos dois problemas clássicos: a tabela de categorias sofreu um Seq Scan desnecessário, e a de produtos também. Faltam índices nos filtros usados: slug e price. Criando dois índices simples, a situação muda completamente.

CREATE INDEX idx_categories_slug ON categories(slug);
CREATE INDEX idx_products_price ON products(price);

Depois disso, o plano passa para Index Scans, reduzindo drasticamente a leitura de dados.

Como detectar nós custosos em cascata

O EXPLAIN ANALYZE não só mostra cada nó, como também revela o tempo real consumido em cada um deles. A abordagem prática é analisar de cima para baixo procurando trechos que apresentem tempos muito acima da média.

Você também pode usar a métrica “Actual Rows” comparada com “Rows” estimado. Quando a estimativa é muito menor do que o número real, o otimizador erra o plano e isso costuma gerar operações caras, como Nested Loops gigantescos.

Um exemplo:

Nested Loop  (actual time=0.500..3500.000 rows=200000 loops=1)
  -> Index Scan using categories_slug_idx (actual rows=1)
  -> Seq Scan on products p (actual rows=200000)

A leitura de 200 mil linhas dentro de um Nested Loop com apenas um registro da outra ponta indica um plano ineficiente. Muitas vezes, um Hash Join seria mais rápido. Se as estatísticas estiverem desatualizadas, o PostgreSQL pode ter escolhido um plano errado.

Nessas horas, vale rodar:

ANALYZE products;

Com as estatísticas atualizadas, a escolha do plano costuma melhorar.

Esse tipo de análise em cascata é o que vai revelar onde está o gargalo. O PostgreSQL sempre explica tudo no plano, basta interpretar os nós e entender como cada etapa afeta o desempenho geral da query.

Usando o pg_stat_statements para encontrar queries pesadas

Quando a aplicação começa a ficar lenta e o banco parece estar sempre sobrecarregado, uma das formas mais eficientes de descobrir o que realmente está acontecendo é usando a extensão pg_stat_statements. Ela registra estatísticas de todas as queries executadas, permitindo identificar quais são as mais pesadas, quais se repetem demais e quais gastam mais tempo acumulado. É uma visão real do comportamento da aplicação, não apenas de um caso isolado.

Como habilitar pg_stat_statements

A extensão costuma vir instalada por padrão, mas não habilitada. O primeiro passo é ativá-la no arquivo postgresql.conf. Basta editar o parâmetro shared_preload_libraries e incluir a extensão.

shared_preload_libraries = 'pg_stat_statements'

Depois disso, reinicie o servidor e crie a extensão no banco desejado:

CREATE EXTENSION pg_stat_statements;

Também é comum ajustar o tamanho do histórico:

pg_stat_statements.max = 10000
pg_stat_statements.track = all

Esses parâmetros aumentam a quantidade de queries armazenadas e garantem que tudo seja rastreado.

Consultas prontas para descobrir as mais lentas

Com a extensão ativa, você pode extrair rapidamente as consultas que estão consumindo mais tempo total.

SELECT 
    query,
    total_time,
    mean_time,
    calls
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

Se o objetivo é encontrar queries raras, porém extremamente lentas, pode usar a média:

SELECT 
    query,
    mean_time,
    calls
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

Quer identificar as que mais entopem o banco pela quantidade de chamadas?

SELECT 
    query,
    calls,
    total_time
FROM pg_stat_statements
ORDER BY calls DESC
LIMIT 10;

Essas consultas ajudam a descobrir padrões: talvez a query não seja lenta individualmente, mas seja chamada milhares de vezes e esteja sobrecarregando o servidor.

Analisando tempo médio, variação e quantidade de execuções

A interpretação das métricas é direta, mas cada campo conta uma parte da história.

total_time mostra o tempo acumulado gasto pela query. mean_time mostra o tempo médio por execução. calls é quantas vezes ela foi executada. Uma query com mean_time baixo mas calls enorme pode ser pior que uma query com mean_time alto que roda poucas vezes. Em ambientes web isso acontece o tempo todo.

Um exemplo prático:

query: SELECT * FROM products WHERE category_id = $1
calls: 320000
total_time: 18500ms
mean_time: 0.057ms

Aqui a query é rápida individualmente, mas chamada milhares de vezes. Isso pode indicar falta de cache na aplicação ou um endpoint sendo acessado mais do que deveria. Em outro cenário:

query: SELECT * FROM users WHERE email LIKE '%gmail.com'
calls: 120
total_time: 9600ms
mean_time: 80ms

Agora o problema é o padrão de filtros, provavelmente um LIKE sem índice adequado.

Identificando padrões de gargalo

Depois de listar as queries, o próximo passo é notar padrões. Alguns aparecem com frequência:

Filtros usando LIKE com wildcard no início.
JOINs sem índices nas colunas relacionadas.
Queries simples sendo executadas em loop dentro da aplicação.
Consultas que poderiam ser agregações, mas recebem dados demais.
Endpoints que repetem a mesma query várias vezes sem necessidade.

Um padrão comum é encontrar queries muito parecidas, mas com parâmetros diferentes. Isso pode ser um sinal de que a aplicação está recalculando dados que poderiam ser pré-processados.

Você também pode agrupar queries pela estrutura usando o queryid. Isso ajuda a identificar quando pequenas variações estão mascarando um gargalo maior.

SELECT 
    queryid,
    sum(total_time) AS total_time_sum,
    sum(calls) AS total_calls
FROM pg_stat_statements
GROUP BY queryid
ORDER BY total_time_sum DESC;

Assim fica claro qual grupo de queries está drenando mais recursos.

O pg_stat_statements é essencial justamente por trazer a visão global do uso do banco. Ele revela o que realmente acontece no dia a dia da aplicação, não apenas em momentos isolados. A partir daí, fica muito mais simples priorizar otimizações e atacar os gargalos de forma direta.

Checklist de diagnóstico rápido (para usar no dia a dia)

Quando uma consulta começa a demorar mais do que deveria, é importante ter um fluxo de verificação simples e direto para identificar os problemas mais comuns. Esse checklist ajuda a entender rapidamente se o gargalo vem de índices, estatísticas, uso de memória, funções na cláusula WHERE ou da própria estrutura da query.

Query está fazendo Seq Scan desnecessário?

O primeiro ponto é verificar se a consulta está percorrendo a tabela inteira sem necessidade. O Seq Scan é normal em algumas situações, mas quando existe um índice adequado e mesmo assim o PostgreSQL ignora, algo está errado.

EXPLAIN
SELECT * FROM users WHERE email = '[email protected]';

Se o plano mostrar Seq Scan, verifique a existência de um índice:

CREATE INDEX idx_users_email ON users(email);

Também é importante garantir que a consulta seja compatível com o índice. Por exemplo, usar LOWER(email) sem um índice funcional força o Seq Scan.

SELECT * FROM users WHERE LOWER(email) = '[email protected]'; -- Seq Scan

A solução seria criar um índice funcional:

CREATE INDEX idx_users_email_lower ON users(LOWER(email));

Estimativas do planner estão incorretas?

Quando o otimizador erra na estimativa de rows, ele pode escolher planos ruins. Isso tende a acontecer quando as estatísticas estão desatualizadas ou quando a distribuição de valores é desigual.

ANALYZE users;

Também vale ajustar a amostragem de estatísticas quando a tabela é muito grande ou tem valores muito concentrados.

ALTER TABLE users ALTER COLUMN status SET STATISTICS 500;

Ao comparar estimated rows e actual rows no EXPLAIN ANALYZE, diferenças grandes indicam problema:

EXPLAIN ANALYZE
SELECT * FROM orders WHERE status = 'pending';

Se estimated = 100 e actual = 20000, o planner está tomando decisões com uma visão distorcida da tabela.

Cache e buffers estão sendo usados corretamente?

O PostgreSQL depende fortemente de cache. Quando o sistema está com pouco shared_buffers ou o sistema operacional está sempre trocando páginas, consultas simples viram gargalos.

Para verificar:

SELECT blks_hit, blks_read, 
       blks_hit::numeric / (blks_hit + blks_read) AS hit_ratio
FROM pg_stat_database
WHERE datname = current_database();

Um hit ratio muito abaixo de 0.95 costuma indicar falta de cache, excesso de varreduras completas ou tabelas muito grandes sem filtros adequados.

Também vale analisar consumo de memória dentro de operações de ordenação:

SET work_mem = '64MB';

Configurações inadequadas podem fazer o PostgreSQL usar disco para sort e hash, deixando tudo lento.

Query está filtrando cedo ou tarde demais?

A ordem lógica da consulta faz diferença. Filtrar cedo reduz o volume de dados que passa para os próximos nós da execução. Filtrar tarde faz todos os nós trabalharem mais do que deveriam.

Uma consulta como:

SELECT *
FROM sales
JOIN customers ON customers.id = sales.customer_id
WHERE customers.active = true;

Pode ficar mais leve ao primeiro garantir que exista índice no filtro e no join. Já consultas com filtros em subqueries podem atrasar o processo e obrigar o PostgreSQL a processar mais linhas que o necessário.

Compare essa versão problemática:

SELECT *
FROM (
    SELECT * FROM sales
) s
WHERE s.amount > 1000;

Com a versão simplificada:

SELECT *
FROM sales
WHERE amount > 1000;

O PostgreSQL geralmente otimiza, mas nem sempre. Analisar o plano ajuda a ver se o filtro está sendo aplicado cedo ou depois de uma operação mais custosa.

Existe função na cláusula WHERE?

Funções no WHERE podem invalidar índices, forçar Seq Scan e multiplicar o tempo da consulta.

SELECT * FROM users
WHERE DATE(created_at) = CURRENT_DATE;

Esse tipo de filtro ignora o índice de created_at. O correto seria:

SELECT * FROM users
WHERE created_at >= CURRENT_DATE
  AND created_at < CURRENT_DATE + INTERVAL '1 day';

Outro exemplo comum:

SELECT * FROM products
WHERE LOWER(name) = 'iphone';

Sem índice funcional, isso causa Seq Scan. A correção:

CREATE INDEX idx_products_name_lower ON products(LOWER(name));

E a query permanece igual, mas agora usa o índice.

Esse checklist funciona como um passo a passo rápido para detectar os problemas mais recorrentes. Ele não substitui uma análise profunda com EXPLAIN ANALYZE e pg_stat_statements, mas é ideal para o dia a dia quando você precisa diagnosticar e corrigir rapidamente as causas mais óbvias de lentidão.

Soluções comuns para problemas de performance

Depois de identificar por que uma consulta ficou lenta, chega o momento de ajustar o que realmente importa. A maior parte das correções de performance no PostgreSQL gira em torno de três pilares: melhorar a forma como a query é escrita, garantir que o banco tenha informações corretas para escolher o melhor plano e ajustar configurações que evitam operações pesadas em disco. Esse conjunto de práticas costuma resolver a maior parte dos gargalos do dia a dia.

Reescrever filtros e JOINs

Grande parte dos problemas está na forma como a query foi escrita. Filtros mal posicionados, JOINs feitos sem necessidade ou sem índice no campo de ligação e condições usando funções no WHERE são causas clássicas de lentidão.

Um exemplo comum de JOIN custoso:

SELECT *
FROM orders o
JOIN customers c ON LOWER(c.email) = LOWER(o.customer_email);

Esse tipo de comparação impede o uso de um índice normal. Uma solução melhor é normalizar os dados ou criar um índice funcional:

CREATE INDEX idx_customers_email_lower ON customers(LOWER(email));

E ajustar o JOIN:

SELECT *
FROM orders o
JOIN customers c ON LOWER(c.email) = o.customer_email;

Outra situação comum é filtrar tarde demais. Filtrar cedo reduz o volume de dados que passa para os outros nós:

SELECT *
FROM sales s
JOIN customers c ON c.id = s.customer_id
WHERE s.amount > 500;

Se o filtro estiver dentro de uma subquery, pode atrasar todo o plano. Reescrever a query de forma mais direta costuma melhorar bastante o desempenho.

Atualizar estatísticas (ANALYZE)

Se o planner erra estimativas de linhas, ele escolhe planos ruins. Muitas vezes, só atualizar estatísticas já resolve o problema.

ANALYZE;

Se uma tabela recebe atualizações frequentes e possui valores concentrados, é útil aumentar a profundidade das estatísticas:

ALTER TABLE sales ALTER COLUMN status SET STATISTICS 500;
ANALYZE sales;

Só essa mudança pode fazer o planner trocar um Seq Scan por um Index Scan, reduzir custos de Hash Join ou melhorar filtros seletivos.

Ajustar configurações (work_mem, shared_buffers, effective_cache_size)

Quando o PostgreSQL não tem memória suficiente, operações como sort e hash vão para disco, o que derruba o desempenho.

Para testar uma configuração melhor temporariamente:

SET work_mem = '64MB';

Para enviar para o arquivo de configuração:

• work_mem: memória para ordenações e operações de hash
• shared_buffers: memória usada pelo PostgreSQL para cache interno
• effective_cache_size: estimativa do cache total disponível (PostgreSQL + SO)

Um exemplo de ajuste comum em servidores dedicados:

shared_buffers = 4GB
work_mem = 64MB
effective_cache_size = 12GB

Esses valores dependem do ambiente, mas ajustar corretamente muitas vezes evita operações lentas gravadas no EXPLAIN ANALYZE como “Disk: …”.

Reduzir cardinalidade desnecessária

Quanto mais linhas o PostgreSQL precisa manusear, mais pesado fica cada nó. Reduzir cardinalidade significa diminuir o número de linhas processadas, seja filtrando melhor, seja reorganizando a consulta.

Exemplo problemático:

SELECT *
FROM orders
WHERE created_at >= NOW() - INTERVAL '2 years';

Se a tabela tem milhões de registros, isso pode ser enorme. Uma alternativa é trabalhar com partições ou restringir mais o filtro quando possível:

SELECT *
FROM orders
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days';

Outra forma de reduzir cardinalidade é evitar SELECT * em tabelas grandes. Consultar apenas colunas necessárias reduz IO e largura das linhas:

SELECT id, customer_id, amount
FROM orders
WHERE amount > 1000;

Quando criar (ou recriar) índices resolve

Criar um índice novo é uma das soluções mais diretas quando há lentidão, mas nem sempre é a primeira opção. O índice certo melhora filtros, JOINs e ordenações. O índice errado só aumenta o custo de escrita.

Quando o EXPLAIN ANALYZE mostra Seq Scan em consultas filtradas por colunas de alta seletividade, o índice ajuda:

CREATE INDEX idx_sales_amount ON sales(amount);

Se a query faz ORDER BY e o PostgreSQL está fazendo Sort pesado:

CREATE INDEX idx_sales_created_at ON sales(created_at);

E quando o índice já existe mas não está sendo usado porque ficou inchado demais, foi criado errado ou tem baixa correlação, recriá-lo pode resolver:

REINDEX INDEX idx_sales_created_at;

Ou, quando o problema é bloat:

VACUUM FULL;

Esta seção é propositalmente resumida porque a criação e otimização de índices merecem um artigo próprio, mas não dá para ignorar o fato de que índice bem feito costuma ser uma das soluções mais eficientes para a maioria dos problemas de performance.

Se quiser, posso continuar com o próximo tópico ou revisar a estrutura do artigo inteiro.

Como validar se a otimização funcionou

Depois de ajustar a consulta, criar índices, reescrever filtros ou mexer em configurações, chega a hora de validar se tudo realmente fez diferença. É comum achar que uma mudança melhorou o desempenho, mas só o EXPLAIN ANALYZE e medições objetivas mostram se houve impacto real. A validação evita regressões, confirma se o plano mudou e mostra se o banco está usando menos recursos para entregar o mesmo resultado.

Antes e depois com EXPLAIN ANALYZE

O primeiro passo para confirmar que a otimização funcionou é comparar o plano antigo com o novo usando EXPLAIN ANALYZE. O ideal é salvar o plano original para analisar lado a lado.

EXPLAIN ANALYZE
SELECT *
FROM sales
WHERE amount > 500;

O que você precisa observar:

• se o Seq Scan virou Index Scan ou Bitmap Index Scan
• se o tempo total caiu
• se o número de linhas estimadas e reais ficou mais alinhado
• se desapareceram nós de Sort ou Hash para operações simples
• se os Disk I/O reduziram

O EXPLAIN ANALYZE sempre mostra o tempo real e é a ferramenta mais precisa para validar ganhos. Mesmo que o plano continue parecido, o tempo pode cair por causa de buffers agora bem utilizados ou porque as estatísticas foram atualizadas.

Medindo impacto real no tempo de execução

Além do EXPLAIN ANALYZE, é importante medir o tempo de execução real da query repetidas vezes para descartar variações aleatórias.

SELECT now();
SELECT * FROM sales WHERE amount > 500;
SELECT now();

Você também pode usar o comando timing no psql:

\timing on
SELECT * FROM sales WHERE amount > 500;

Para medições consistentes, execute a consulta várias vezes. A primeira rodada costuma ser influenciada pelo cache frio. As próximas execuções mostram o comportamento real do banco com buffers carregados.

Checando impacto em carga de produção

O ambiente de produção pode ter comportamento bem diferente, principalmente quando existe concorrência, alto volume de escrita ou consultas simultâneas competindo pelo mesmo índice. Depois de validar localmente, o ideal é monitorar as estatísticas de espera e como o servidor se comporta com a mudança aplicada.

Algumas consultas úteis:

Tempo médio das queries mais executadas:

SELECT query, mean_time, calls
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

Queries que mais consumiram tempo total:

SELECT query, total_exec_time, calls
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Se uma otimização realmente funcionou, você verá queda consistente em mean_time e possivelmente total_exec_time, mesmo com um número alto de chamadas.

Ajustes finais e boas práticas

Depois de validar o desempenho, geralmente falta acertar alguns detalhes:

• testar com diferentes valores para work_mem em consultas envolvendo ordenações
• verificar se algum índice recém-criado está realmente sendo utilizado em todos os cenários esperados
• checar se a alteração não piorou outras partes do sistema
• monitorar novamente após algumas horas de uso em produção
• documentar a melhoria e o motivo da alteração

Registrar o antes e depois evita que o time perca contexto no futuro e garante que decisões técnicas sejam baseadas em dados.

Conclusão

Manter consultas rápidas no PostgreSQL não é um evento isolado. É um processo contínuo. Sempre que uma tabela cresce, sempre que uma carga muda ou quando novas funcionalidades entram no sistema, o desempenho pode ser impactado. Um checklist simples ajuda a manter tudo sob controle.

• verificar se existe índice adequado para cada filtro e JOIN crítico
• evitar funções na cláusula WHERE quando possível
• atualizar estatísticas periodicamente, principalmente após cargas grandes
• revisar queries que fazem Seq Scan em tabelas grandes
• analisar alterações no plano usando EXPLAIN ANALYZE sempre que algo ficar lento
• monitorar pg_stat_statements para encontrar gargalos antes que o usuário perceba
• manter configurações ajustadas ao tamanho do servidor e do banco

Seguindo esse checklist, a maior parte dos problemas de performance aparece cedo e é corrigida rápido, antes de virar um problema maior. Com o tempo, esse processo vira parte natural do desenvolvimento, e o banco se mantém estável e rápido mesmo com crescimento de dados e aumento de carga.