Treinar um modelo de 4B para produzir planos de consulta 81% mais rápidos que o Postgres
Uma postagem de blog afirma que um modelo de linguagem de 4 bilhões de parâmetros pode gerar planos de consulta PostgreSQL cerca de 81% mais rápidos em um benchmark pequeno e em memória, o que provocou debate sobre se LLMs devem entrar na otimização central de bancos de dados. Comentadores questionam a praticidade de re-treinar modelos, a omissão do tempo de planejamento nas afirmações de desempenho e o risco de overfitting a cargas de trabalho estreitas, enquanto observam que heurísticas tradicionais baseadas em custo e ML já sofrem com distribuições de dados mutáveis. Muitos veem potencial para uso offline ou híbrido — por exemplo, gerar dicas para consultas problemáticas — em vez de substituir planejadores maduros e determinísticos em sistemas reais, de alto throughput.
Correção e o que o LLM realmente controla
- Vários perguntam como se sabe que o plano produzido pelo LLM ainda calcula a consulta corretamente.
- Esclarecimento: o LLM não reescreve SQL; ele apenas ajusta configurações/dicas do planejador. O Postgres ainda verifica a validade do plano e faz fallback se as dicas não corresponderem a um plano legal.
- Alguns sugerem verificação de equivalência ou ferramentas de prova, mas outros observam que provar equivalência completa é indecidível/NP-difícil em geral.
Determinismo, estatísticas e deriva da carga de trabalho
- Planos de consulta não são determinísticos; eles dependem de estatísticas, valores de parâmetros e da forma dos dados.
- Cargas de trabalho do mundo real frequentemente veem regressões súbitas de plano quando as estatísticas mudam ou padrões raros de cardinalidade aparecem.
- Dicas ou planos aprendidos podem se tornar inválidos quando as distribuições de dados ou as cargas de trabalho derivam, limitando o valor de uma otimização offline “uma vez e pronto”.
Afirmações de desempenho e realismo do benchmark
- Vários comentaristas questionam o ganho de 81%:
- O conjunto de dados é pequeno (8 GB), cabe na memória, as consultas estão aquecidas, são SELECTs somente leitura.
- Preocupação com overfitting a esse ambiente e falta de evidências em sistemas OLTP/HTAP grandes e em evolução.
- Alguns observam que parâmetros do Postgres mal ajustados (por exemplo, random_page_cost, índices ou estatísticas ausentes) por si só podem explicar grandes diferenças.
- Outros apontam que o projeto ignora a latência de planejamento; um planejador prático precisa melhorar “planejamento + execução” sob restrições ao vivo.
LLMs vs outras abordagens
- Muitos argumentam que ML clássico ou redes neurais especializadas (heurísticas no estilo AlphaGo, GNNs) seriam mais apropriadas do que um LLM geral.
- Ferramentas existentes como otimização baseada em custo, histogramas do Postgres, GEQO e heurísticas aprendidas em compiladores são citadas como precedentes mais direcionados.
- Alguns veem os LLMs como excessivos e difíceis de depurar; outros os consideram promissores para exploração offline e destilação em modelos menores.
Risco operacional e modelos de uso
- Ceticismo sobre adicionar um modelo de 4 bilhões de parâmetros ao caminho crítico de produção de um banco de dados, especialmente em alto QPS.
- Mais entusiasmo pelo uso offline ou em tempo de teste: clonar produção, analisar consultas lentas, gerar dicas, commitá-las no controle de versão e verificar via testes.
- Permanecem preocupações sobre não determinismo, risco de regressão e incompatibilidade de habilidades para equipes de banco de dados que gerenciam componentes baseados em LLM.
Outros temas
- Discussão sobre possível aceleração por GPU para joins/sorts versus planejadores mais inteligentes.
- Menções a planos de consulta adaptativos (troca de plano no meio da execução) como o “endgame” de longo prazo.
- Debate lateral sobre a ética da destilação e o ecossistema de IA mais amplo, além de elogios à clareza e à qualidade visual do texto.