Modelo de 4B parâmetros gera planos de query 81% mais rápidos que o Postgres

A tese: um modelo pequeno pode vencer o otimizador do Postgres

O engenheiro Rohan Bansal conduziu um experimento para responder se um modelo de pesos abertos de 4 bilhões de parâmetros, pós-treinado com fine-tuning supervisionado (SFT) e aprendizado por reforço agêntico (RL), consegue gerar dicas que fazem o Postgres executar queries mais rápido do que com seus planos padrão. A resposta, segundo o autor, é um "sim retumbante": o modelo alcançou uma redução de latência de 44,7% em 113 queries com muitas junções do benchmark JOB - queries para as quais o modelo inicialmente não conseguia produzir um plano válido em 99 casos. O título do artigo fala em planos de query 81% mais rápidos, resultado associado à métrica de speedup geométrico que ele constrói ao longo do texto.

Por que otimizadores de query são difíceis

Bansal parte da pesquisa de Leis et al. (2015, revisitada dez anos depois), que mostrou que otimizadores de query continuam deixando a desejar. Um dos problemas centrais, a ordenação de junções (join ordering), é NP-hard. O Postgres não pode contar cardinalidades reais durante o planejamento - isso exigiria executar cada junção - e por isso usa estatísticas da tabela pg_statistic, assumindo distribuição uniforme entre tabelas. Quando essa premissa falha (por exemplo, se 5% das empresas japonesas respondem por 50% dos filmes), uma estimativa ruim no início da árvore de junções se propaga e corrompe todo o plano. O espaço de busca também explode combinatorialmente: uma query de 12 tabelas, considerando árvores de junção, orientações, algoritmos (hash, merge, nested loop) e tipos de scan, tem mais de 10^25 planos possíveis.

A formulação do problema

Em vez de tentar construir um estimador de cardinalidade melhor - o que enfrentaria décadas de pesquisa e teria latência de inferência proibitiva -, o autor foca em workloads analíticos pesados, em que as mesmas queries rodam milhares de vezes. O custo de treinamento (executar a query dezenas a centenas de vezes) se amortiza ao longo das execuções. A meta não é vencer o Postgres em queries one-off, mas sim em queries repetidas.

O ferramental

O modelo escolhido foi o empero-ai/Qwen3.8-4B-Distill, uma destilação do laboratório alemão Empero a partir do Qwen 3.8 2.4T (o autor optou por ele mesmo sem saber se é melhor que o modelo base para a tarefa). Para orquestrar a produção de dicas, ele construiu um agente leve, o qo-agent, com seis ferramentas (inspeção de tabelas, estatísticas de colunas, avaliação de candidatos, entre outras). As dicas são inseridas via extensão pg_hint_plan, que permite forçar junções, scans e ordem de junção por meio de comentários no SQL.

Benchmarks e dados

O treino usou o Cardinality Estimation Benchmark (CEB), com cerca de 13,6 mil queries sintéticas sobre o dataset IMDb, e a validação usou o Join Order Benchmark (JOB), de Leis et al., com 113 queries em 33 templates. O autor defende treinar e testar no IMDb: o objetivo é justamente que o modelo aprenda bem uma base específica, como aconteceria num workload corporativo real. Para evitar overfitting, ele mapeou as topologias (grafos de junção) e verificou que não havia sobreposição entre CEB e JOB, dispensando filtragem.

Treinamento e resultados

O treinamento combinou SFT off-policy (destilando cerca de quinhentas trajetórias de agente do GPT-6 Astra, com LoRA para adaptação de baixo rank) e RL agêntico com uma variante própria de GRPO, desenhada para atribuir recompensas por rollout num ambiente ruidoso: cada rollout propõe uma estratégia que é medida contra o plano padrão do Postgres, e as recompensas escalares fluem de volta para atualizar os pesos. A infraestrutura dividia o RL entre duas máquinas - vLLM e o treinador num nó alugado com 2x H100, e quatro containers Postgres no computador pessoal do autor, com um rig de medição que minimiza o ruído do page cache do Linux. O texto detalha ainda métricas como speedup geométrico e speedup total do workload, além de baselines (o modelo 4B puro e um controle com um modelo de fronteira).

Conclusão

O experimento mostra que um modelo de 4B parâmetros, quando pós-treinado para produzir dicas verificáveis de plano de query, pode superar o otimizador padrão do Postgres em queries repetidas de workload analítico - com o autor encerrando apontando próximos passos e disponibilizando código.