Introdução à análise de performance de queries

Deixa eu começar com uma história real. Imagina que você trabalha como dev numa plataforma gigante de e-commerce. Tudo roda liso, menos um detalhe: o relatório de vendas do mês é tão lento que o usuário consegue fazer outro pedido antes dele terminar. Você fica nervoso, seu gerente fica nervoso, o servidor PostgreSQL ferve igual chaleira, e tudo parece o fim do mundo. Agora imagina se você pudesse achar o motivo e resolver rapidinho.

Analisar a performance das queries é tipo fazer um check-up no seu PostgreSQL. Ajuda a achar os “gargalos” (as dores) e corrigir pra melhorar a experiência do usuário e economizar recursos do sistema.

Como as queries funcionam por baixo dos panos no PostgreSQL?

Quando você escreve uma query simples tipo:

SELECT * FROM products WHERE price > 100;

O PostgreSQL não sai pegando os dados na hora. Primeiro ele analisa sua query, pensa em como executar melhor, e só depois começa a trabalhar.

Principais etapas de execução de queries:

1. Parsing. O PostgreSQL checa se sua query tem erro de sintaxe e transforma ela numa representação intermediária.
2. Otimização. O otimizador de queries avalia vários jeitos de executar e escolhe o mais “barato” (em tempo e recursos).
3. Execução. O servidor segue o plano escolhido e busca os dados.

O que é um “gargalo”?

“Gargalo” é a parte da query que trava o resto. Pode ser uma operação que do nada consome mais tempo ou recurso que o esperado. Por exemplo, se o PostgreSQL faz um scan completo na tabela (Seq Scan) ao invés de usar um índice, a query fica lenta. Ou se tem muito mais dados do que o planejado, e o servidor perde tempo pra caramba ordenando, juntando, filtrando.

Esses são os tais gargalos — são eles que você tem que caçar e otimizar primeiro.

Ferramentas pra analisar performance de queries

No PostgreSQL tem umas ferramentas bem potentes pra te ajudar a achar problemas nas queries:

1. EXPLAIN e EXPLAIN ANALYZE. Esses comandos mostram como o PostgreSQL pretende executar a query, ou até executam de verdade pra medir a performance real.

• EXPLAIN: mostra o plano de execução sem rodar a query de verdade.
• EXPLAIN ANALYZE: executa a query e mostra o plano real com métricas de tempo.

Exemplo de uso do EXPLAIN:

EXPLAIN SELECT * FROM products WHERE price > 100;

Saída:

Seq Scan on products  (cost=0.00..35.50 rows=5 width=72)
  Filter: (price > 100)

Aqui mostra que a query faz um “Seq Scan” — scan completo da tabela, que é ruim pra tabelas grandes.

2. pg_stat_statements. É uma extensão extra que monitora as queries executadas. Ela mostra:

• Quais queries estão rodando no servidor.
• Quanto tempo cada query leva.
• Quantas linhas a query retorna e quanto recurso consome.

Pra ativar o pg_stat_statements, faz assim:

1. Ativa a extensão:

CREATE EXTENSION pg_stat_statements;

2. Configura o PostgreSQL: No arquivo postgresql.conf adiciona:

   shared_preload_libraries = 'pg_stat_statements'
   pg_stat_statements.track = all

3. Reinicia o PostgreSQL.

Agora você pode analisar as queries:

SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;

Isso mostra as 5 queries mais “pesadas” em ordem decrescente de tempo total.

3. Log de queries lentas. Você pode configurar o PostgreSQL pra registrar queries que demoram demais (tipo mais de 1 segundo) num arquivo de log.

Pra isso, no postgresql.conf coloca:

log_min_duration_statement = 1000  # Tempo em milissegundos (1 segundo)

Agora as queries lentas vão ficar salvas nos logs do PostgreSQL.

Métricas principais pra analisar performance

Quando você for analisar a performance das queries, fica de olho nessas métricas chave:

1. Tempo de execução. É o tempo que a query leva pra rodar. Quanto mais rápido, melhor.
2. Quantidade de linhas. Se sua query retorna ou escaneia mais linhas do que você esperava, pode ser problema.
3. Uso de índices. Se a query deveria usar índice mas faz scan sequencial (Seq Scan), é sinal de que precisa otimizar.
4. Buffers e operações em disco. Queries que mexem muito com disco são mais lentas do que as que usam dados da memória.

Como aplicar isso na prática?

Exemplo 1: Query lenta

Você escreve uma query pra buscar todos os produtos com preço maior que 100:

SELECT * FROM products WHERE price > 100;

Você percebe que a query tá demorando demais. Usa o EXPLAIN e vê:

Seq Scan on products  (cost=0.00..35.50 rows=5 width=72)
  Filter: (price > 100)

Problema: a query faz scan completo porque não tem índice na coluna price.

Solução:

Cria um índice:

CREATE INDEX idx_price ON products(price);

Agora a query usa Index Scan:

Index Scan using idx_price on products  (cost=0.15..8.25 rows=5 width=72)
  Index Cond: (price > 100)

Exemplo 2: Encontrando queries lentas com pg_stat_statements

Com o comando:

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

Você descobre uma query que tá gastando muito tempo pra rodar. Abre ela com EXPLAIN ANALYZE, corrige, e ela fica mais rápida.

Quando você começar a usar EXPLAIN, pg_stat_statements e outras ferramentas, suas queries vão voar, e seu servidor PostgreSQL vai rodar igual relógio suíço. Na próxima aula a gente vai mergulhar nos detalhes dos parâmetros do EXPLAIN, tipo cost, rows e width, pra você ler planos de execução como se fosse livro aberto.