O que realmente acontece quando você pergunta questões sobre pg no dia a dia
Muita gente entra em fóruns ou grupos perguntando coisas genéricas como "por que meu PostgreSQL tá lento" e acaba recebendo respostas que não resolvem nada. O problema não é a falta de informação disponível. O problema é que as pessoas não sabem quais detalhes incluir quando fazem essas questões sobre pg, então o diagnosticador não tem material suficiente pra chegar num veredito. Quando você vai fazer uma pergunta técnica sobre PostgreSQL, o primeiro passo é listar exatamente o que já tentou. Não adianta só jogar o erro na parede e esperar que alguém adivinhe. Eu já vi gente postando screenshots inteiras de tabelas com mil linhas sem nenhum contexto. Isso não ajuda ninguém.
questoes sobre pg que realmente recebem resposta útil
As questões sobre pg que funcionam são aquelas que seguem um padrão mínimo de informação. Você precisa informar a versão do PostgreSQL, o sistema operacional, a configuração de hardware relevante e, acima de tudo, o resultado de um EXPLAIN ANALYZE na query problemática. Sem isso, qualquer conselho é chute. E chute em banco de dados é o jeito mais rápido de criar um problema novo enquanto tenta resolver outro. Recentemente precisei ajudar alguém com uma query que levava 47 segundos pra rodar. A pessoa só tinha dito "meu select tá lento". Pedi o EXPLAIN ANALYZE, olhei o plano de execução e vi que o PostgreSQL estava fazendo um sequential scan numa tabela de 12 milhões de linhas que tinha um índice B-tree em uma coluna usada no WHERE. O índice existia, mas o otimizador simplesmente decidia ignorá-lo porque achava que ler a tabela inteira era mais barato. Quando ajustei o parâmetro random_page_cost de 4.0 para 1.1 — valor adequado pro ambiente dela que era SSD — a query caiu para 230ms. Sozinha, sem nenhuma outra mudança. Esse tipo de ajuste é o tipo de coisa que só aparece quando você vê o plano real, não quando lê fóruns.
Erros comuns que todo mundo comete nas questões sobre pg
A primeira coisa que as pessoas esquecem é a versão. PostgreSQL 14 se comporta diferente de PostgreSQL 16 em diversos aspectos, especialmente na parte de paralelismo de queries e no plano de execução de joins. Um workaround que funcionava na versão 12 pode ser completamente inútil ou até pior na 15. Sempre indique a versão no início da sua questão. O segundo erro grave é não mostrar o schema. Pedir ajuda sem mostrar o CREATE TABLE das tabelas envolvidas é como levar um mecânico até o carro e dizer só "está fazendo um barulho estranho". As colunas, os tipos, os constraints, os índices — tudo isso importa. Uma coluna do tipo text com índices que não consideram collation pode causar comportamentos totalmente diferentes de uma coluna varchar.
Também tem gente que posta questões sobre pg sem mencionar o workload. Uma configuração que funciona perfeitamente pra um sistema de leitura pesada (OLAP, data warehouse) vai falhar miseravelmente num sistema de escrita intensa (OLTP). O work_mem, o shared_buffers, o effective_cache_size — todos esses parâmetros precisam ser pensados junto com o padrão de acesso. Usar a configuração padrão do postgresql.conf em produção é um dos erros mais comuns que eu vejo, e não é por maldade. É porque o arquivo de configuração padrão foi projetado pra rodar em qualquer máquina, o que significa que ele não é otimizado pra nenhuma máquina específica.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como estruturar uma pergunta que gera resposta técnica de verdade
Eu recomendo começar com um resumo de duas linhas do problema, depois colar o EXPLAIN ANALYZE, o schema das tabelas relevantes e a configuração atual dos parâmetros que parecem mais afetados. Se a query usa funções definidas pelo usuário, procedures armazenadas ou triggers, inclua também o código dessas definições. Otimizador do PostgreSQL é determinístico — dado o mesmo input, ele produz o mesmo plano. Então se você consegue reproduzir o cenário completo, quem for responder também consegue. Um detalhe que poucas pessoas levam em conta é o autovacuum. Muitas questões sobre pg que parecem ser sobre performance de query na verdade são sobre tabela suja. Quando uma tabela passa por muitas deleções ou atualizações sem um vacuum adequado, as tuplas mortas se acumulam e o sequential scan fica mais lento porque precisa varrer dados que não existem mais. Verifique o relfrozenxid e o count de tuplas mortas com uma consulta simples no pg_stat_user_tables. Se o número de tuplas mortas estiver na casa dos milhões numa tabela que já foi moderadamente grande, o vacuum está atrasado e isso explica metade dos problemas de performance que as pessoas reportam.
Sempre inclua também o resultado do SHOW ALL ou pelo menos dos parâmetros principais: shared_buffers, work_mem, effective_cache_size, maintenance_work_mem, max_connections e random_page_cost. Esses seis valores sozinhos já dão uma ideia sólida do quanto a configuração atual está distante do ideal. Num servidor com 64GB de RAM rodando PostgreSQL 15 com workload misto, eu normalmente começaria com shared_buffers em 16GB, effective_cache_size em 48GB, work_mem em 64MB e random_page_cost em 1.1. Esses são pontos de partida, não valores definitivos. Mas são pontos de partida que evitam os dois ou três erros mais devastadores que vejo em configurações padrão.
O que fazer quando ninguém responde suas questões sobre pg
Se sua pergunta não recebeu resposta em 24 horas, o problema quase sempre é falta de informação, não complexidade do assunto. Releia o que você postou e sequee: tem versão? Tem EXPLAIN ANALYZE? Tem schema? Tem contexto do workload? Se a resposta for não pra qualquer uma dessas, reformule a pergunta incluindo pelo menos o que falta. Não adianta bump com "alguém pode me ajudar?" — isso só enfraquece a visibilidade do tópico. Outra estratégia que funciona é quebrar o problema. Em vez de pedir ajuda com o sistema inteiro, isola uma query específica, uma tabela específica ou um parâmetro específico. Questões sobre pg bem delimitadas recebem respostas bem delimitadas. Questões genéricas recebem sugestões genéricas que ninguém usa.
Quem mexe com PostgreSQL no dia a dia também aprende que nem toda lentidão é problema de banco. Às vezes a query é lenta porque a aplicação faz N+1 queries num loop, às vezes é porque o rede entre a aplicação e o servidor de banco tem latência alta, às vezes é porque o disco do servidor de banco está compartilhado com outro serviço pesado. Antes de postar questões sobre pg, gaste cinco minutos verificando métricas básicas do sistema: uso de CPU, I/O wait, latência de rede. Se iowait está acima de 20% sustained, o gargalo provavelmente não está no PostgreSQL em si, e sim no subsistema de storage. Mudar configurações de banco não resolve isso. O que separa uma dúvida técnica resolvida de uma que fica looping infinito é a qualidade dos dados que você entrega pra quem vai responder. Quanto mais precisamente você conseguir descrever o problema com dados concretos, menor o tempo até uma resposta útil. Isso vale pra qualquer fórum técnico, não só pra questões sobre pg.
