O que há de novo no planejador de consultas do Postgres 16
As melhorias no planejador de consultas do PostgreSQL 16 estão reacendendo o escrutínio sobre como o banco escolhe e executa planos de consulta, especialmente em torno de escolhas mais arriscadas, como nested loop joins, e do impacto de estatísticas incompletas. Os participantes ponderam o debate de longa data sobre adicionar dicas de consulta ou “congelamento” de planos como saídas de emergência quando o otimizador escolhe planos patológicos, e exploram alternativas como estatísticas melhores, feedback do planejador a partir da execução e ferramentas para visualizar e ajustar planos do EXPLAIN. Eles também destacam problemas práticos — overhead da compilação JIT, falta de cache compartilhado de planos e diferenças em relação a sistemas como o SQL Server — ao mesmo tempo em que concordam, em geral, que o PostgreSQL lida bem com cargas grandes, mas ainda tem espaço para se tornar mais previsível e autocorretivo.
Dicas de Consulta vs. Purismo do Planejador
- Grande debate recorrente: o Postgres deveria oferecer dicas de consulta?
- Argumentos a favor das dicas:
- Cruciais como uma “saída de emergência” quando o planejador escolhe planos terríveis em produção.
- Úteis para mitigação rápida, validação de planos melhores e desempenho consistente entre versões.
- Desejo por dicas fora da banda (por queryid, outlines armazenados) e até capacidades de “congelar este plano”.
- Argumentos contra / preocupações:
- As dicas podem apodrecer à medida que os dados e as versões mudam, fixando planos ruins.
- Elas incentivam maus hábitos de DBA e prejudicam a manutenibilidade.
- A cultura do Postgres prefere corrigir o próprio planejador e usar estatísticas mais ricas em vez de dicas rígidas.
- Ideias de compromisso: dicas mais suaves que influenciem estimativas de seletividade ou tolerância a risco em vez de forçar tipos específicos de join.
Estatísticas, Seletividade e Risco de Plano
- Muitos planos lentos vêm de estimativas ruins de contagem de linhas/seletividade (por exemplo, assumir 1 linha, escolher nested loops e depois obter muitas linhas).
- Discussão sobre estatísticas estendidas, correlações entre colunas e heurísticas atuais (multiplicar probabilidades independentes).
- Desejo por:
- Planejamento mais “averso ao risco” quando as estimativas são incertas.
- Capacidade de expressar conhecimento sobre a forma dos dados (séries temporais monotônicas, tamanho esperado da tabela).
- Feedback do planejador a partir da execução e possivelmente “aprendizado” com planos ruins ao longo do tempo.
- Planejamento de longa duração / multi-pass para consultas OLAP pesadas.
Compilação JIT
- Vários usuários relatam que o JIT torna consultas dramaticamente mais lentas, especialmente consultas com muitos joins ou muitas partições.
- As heurísticas para quando habilitar JIT são vistas como fracas; alguns desativam o JIT globalmente, especialmente para OLTP.
- O código atual de JIT não é cacheado; foi mencionada a necessidade de habilitar cache e melhorar o modelo de custo.
- Sentimento geral: consulta paralela é confiavelmente útil; JIT é poderoso, mas arriscado como padrão.
Inspeção de Planos e Ferramentas
- Ferramentas visuais como visualizadores de explain (pev2, pgMustard, etc.) são valorizadas.
- No entanto, entender se um plano é “ruim” e como corrigi-lo ainda exige conhecimento profundo de joins, índices e estatísticas.
- EXPLAIN ANALYZE é enfatizado como essencial; grandes discrepâncias entre linhas estimadas e reais são sinais de alerta importantes.
Postgres vs. Outros Bancos de Dados
- Alguns afirmam que MSSQL/Oracle têm otimizadores, cache de planos, dicas e ecossistema ao redor (jobs, relatórios, mensagens) mais maduros.
- Outros observam que o Postgres escala bem na prática; as diferenças têm mais a ver com recursos e ferramentas do que com capacidade bruta.