Banco lento? Como rastrear consultas pesadas no PostgreSQL

Por que o PostgreSQL precisa de ajuda para mostrar o que está lento

Quando uma aplicação começa a demorar para responder, a culpa quase sempre recai sobre o banco de dados. O PostgreSQL é extremamente eficiente por padrão, mas ele não avisa espontaneamente qual comando SQL está consumindo mais recursos do servidor. Na prática, isso significa que consultas ineficientes continuam rodando em segundo plano, devorando memória e processador até que o sistema inteiro pare. Para resolver isso, precisamos ativar os registros de rastreamento de consultas lentas, conhecidos no mercado como slow queries.

Muitos desenvolvedores confiam apenas na intuição ou em alertas genéricos de infraestrutura para adivinhar a origem da lentidão. Contudo, sem dados precisos sobre quais registros ou tabelas estão sofrendo, qualquer tentativa de otimização vira um chute no escuro. Antes de aplicar correções complexas ou reestruturar dados, o primeiro passo absoluto é configurar o próprio motor do banco para confessar exatamente quais comandos estão demorando mais do que o aceitável para responder.

Onde mexer: configurando o arquivo postgresql.conf

Toda a mágica do rastreamento no PostgreSQL acontece dentro do arquivo de configuração principal, chamado postgresql.conf. Dependendo de como seu sistema operacional foi configurado, esse arquivo costuma ficar guardado dentro da pasta de dados do banco. Para editá-lo, você precisa ter privilégios de administrador no servidor Linux. Na prática, abrir esse arquivo revela dezenas de parâmetros comentados que controlam desde a memória RAM disponível até a forma como o banco lida com arquivos de log.

Os dois parâmetros fundamentais que você deve procurar são o log_min_duration_statement e o logging_collector. O primeiro define o tempo limite em milissegundos: qualquer consulta que demore mais do que esse valor será registrada automaticamente no arquivo de log do banco. O segundo ativa o coletor interno, que organiza essas mensagens de forma limpa. Para aprofundar sua investigação sobre o comportamento de comandos específicos, vale a pena conferir o guia sobre como usar o EXPLAIN ANALYZE para dissecar o plano de execução.

Passo a passo para ativar o registro de consultas demoradas

Para colocar a mão na massa com segurança, siga os comandos abaixo diretamente no terminal do seu servidor de banco de dados. Lembre-se de ajustar os caminhos conforme a versão do PostgreSQL instalada no seu ambiente de produção ou desenvolvimento.

1. Abra o arquivo de configuração principal usando um editor de texto como o nano com privilégios elevados:
   

   sudo nano /etc/postgresql/15/main/postgresql.conf

2. Localize as linhas correspondentes ao registro de logs e altere os valores para habilitar o rastreamento de consultas acima de duzentos milissegundos:
   

   logging_collector = on
   log_min_duration_statement = 200

3. Salve o arquivo e reinicie o serviço do PostgreSQL para aplicar as novas regras no motor de armazenamento:
   

   sudo systemctl restart postgresql

Identificando gargalos em tabelas gigantescas

Quando tabelas crescem e ultrapassam milhões de linhas, um simples esquecimento de índice transforma uma busca rápida em uma varredura completa de disco. O PostgreSQL faz o que chamamos de sequential scan, ou seja, ele olha linha por linha, do começo ao fim, para encontrar o que você pediu. Quando o volume de dados é gigantesco, essa operação consome todo o subsistema de disco e trava conexões simultâneas. O log de slow query que acabamos de configurar serve exatamente para expor quais tabelas estão sofrendo com esse tipo de leitura massiva e desnecessária.

Outro ponto crítico a observar nos logs gerados é a frequência com que determinadas consultas repetitivas aparecem. Se uma mesma query mal otimizada é disparada centenas de vezes por minuto por uma API lenta que sofre com problemas de conexão e pooling, o impacto acumulado derruba a performance geral do servidor. Cruzar os dados dos logs com ferramentas de monitoramento ajuda a separar o joio do trigo, mostrando se o gargalo é um pico isolado de tráfego ou um erro crônico de arquitetura de software.

Lendo os registros e limpando o caminho crítico

Com os logs ativados e rodando em produção, o próximo desafio é saber ler o que o banco escreveu. Os arquivos de log do PostgreSQL ficam armazenados no diretório de logs padrão e trazem o carimbo de data, hora, o identificador do usuário e o comando SQL exato que estourou o tempo limite. Ler esses arquivos diretamente pode ser cansativo, por isso muitos engenheiros utilizam comandos simples no terminal para filtrar apenas as linhas mais problemáticas da semana.

Para manter o ambiente saudável a longo prazo, combine o rastreamento de logs com uma rotina periódica de manutenção. Analise os relatórios gerados, crie os índices faltantes nas colunas mais buscadas e verifique se a aplicação não está acumulando conexões fantasmas. Garantir a saúde do banco de dados é um processo contínuo que protege a estabilidade do negócio e melhora drasticamente a experiência de quem utiliza o sistema no dia a dia. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como testar relés eletromecânicos com multímetro na bancada.

Considerações finais

Monitorar consultas lentas no PostgreSQL não é um luxo operacional, mas uma necessidade básica para qualquer sistema que pretenda crescer de forma sustentável. Ao configurar corretamente os parâmetros de log e aprender a interpretar os sinais que o banco emite, você substitui a adivinhação por engenharia de precisão. Tabelas grandes deixam de ser uma ameaça fantasma e passam a ser gerenciadas com base em dados reais de performance.

Esperamos que este guia prático ajude você a blindar suas aplicações contra gargalos ocultos. Lembre-se de que a otimização de banco de dados é uma jornada de ajustes constantes, onde cada índice bem colocado representa segundos preciosos salvos para os seus usuários e clientes.