Modello 4B supera l'ottimizzatore di query di Postgres dell'81%

Modello piccolo, grande accelerazione: come un LLM da 4B ha superato l'ottimizzatore di query di Postgres

In una sorprendente dimostrazione di apprendimento per rinforzo applicato, lo sviluppatore Rohan Bansal ha addestrato un modello linguistico da 4 miliardi di parametri a generare piani di query che superano significativamente l'ottimizzatore integrato di PostgreSQL. Il modello, basato su una variante distillata di Qwen, ha ottenuto unaccelerazione media geometrica di 1,81x su 113 query con molti join, traducendosi in unariduzione del 44,7% della latenza totale rispetto ai piani predefiniti di Postgres.

Il progetto, descritto nel post tecnico del blog di Bansal, mostra come un modello relativamente piccolo possa essere ottimizzato per eccellere in un compito ristretto e verificabile—in questo caso, navigare l'esplosione combinatoria degli ordinamenti dei join e delle strategie di scansione. L'intuizione chiave: mentre trovare piani di query ottimali è NP-hard, verificare se un piano è buono è semplice: basta misurare il tempo di esecuzione.

Il problema: l'ottimizzatore di Postgres lascia prestazioni inespresse

Nonostante decenni di ricerca, gli ottimizzatori di query rimangono imperfetti. Come notato in un articolo del 2015 di Leis et al. e ribadito in un follow-up del 2025, gli ottimizzatori spesso producono piani subottimali a causa di stime di cardinalità inaccurate. Postgres si basa su statistiche e presuppone una distribuzione uniforme dei dati, il che può portare a stime errate catastrofiche che si propagano attraverso gli alberi dei join.

Lo spazio di ricerca è sbalorditivo: un semplice join di 3 tabelle ha 4.608 possibili piani di esecuzione, mentre un join di 11 tabelle esplode a oltre 378 sestilioni di combinazioni. Postgres utilizza programmazione dinamica ed euristiche per potare questo spazio, ma può comunque perdere piani migliori.

La soluzione: apprendimento per rinforzo agentico

L'approccio di Bansal ha coinvolto l'uso di pg_hint_plan, un'estensione di Postgres che consente agli sviluppatori di iniettare hint strutturati nei commenti SQL per influenzare il planner. Il modello da 4B, una versione distillata di Qwen 3.8, è stato addestrato come agente che propone questi hint attraverso un harness personalizzato chiamato qo-agent.

La pipeline di addestramento comprendeva due fasi. Prima, ladistillazione off-policy utilizzando 400 traiettorie generate da OpenAI GPT-6 Astra, insegnando al modello il formato di utilizzo degli strumenti dell'harness. Poi, l'apprendimento per rinforzo agentico con una variante personalizzata di GRPO, dove i piani proposti dal modello venivano effettivamente eseguiti su Postgres e premiati in base alle accelerazioni misurate.

Superare il rumore di misurazione

Una sfida critica è stata il rumore di misurazione. Bansal ha scoperto che la cache delle pagine di Linux e i buffer condivisi di Postgres introducevano una variabilità significativa, con alcune query che mostravano tempi di esecuzione bimodali. Attraverso la calibrazione, ha scoperto che aumentare shared_buffers da 128MB a 2GB riduceva il "tasso di inganno" (accelerazioni fantasma dovute al rumore) dal 5% a meno del 2%, rendendo anche le query più veloci in generale.

Risultati e analisi

Il modello finale, dopo 1.200 aggiornamenti dell'ottimizzatore, ha ottenuto:

• Accelerazione media geometrica di 1,81x su tutte le 113 query JOB (selezione best-of-15)
• Riduzione del 44,7% della latenza totale (accelerazione del carico di lavoro di 1,81x)
• Zero regressioni nella selezione del miglior candidato su tre rollout
• Piani candidati validi per 101 query su 113 (rispetto a 14 per il modello vanilla)

Il modello ha appreso diverse strategie efficaci: forzare i join nested loop rispetto agli hash join, preferire le scansioni degli indici, riscrivere gli ordini dei join tramite hint Leading e abilitare l'esecuzione parallela. È interessante notare che ha usato raramente le correzioni Rows, suggerendo che si è concentrato su cambiamenti strutturali piuttosto che su correzioni di cardinalità.

Costo e implicazioni

L'intero progetto è costato circa $1.200, inclusi $800 per il noleggio di H100 e $400 per le API di OpenAI. Ciò dimostra che l'addestramento di modelli piccoli specializzati è accessibile a individui e piccoli team.

Il lavoro di Bansal ha implicazioni più ampie per l'ottimizzazione dei database: invece di fare affidamento su un ottimizzatore universale, le organizzazioni potrebbero addestrare modelli leggeri sui loro carichi di lavoro e database specifici, ammortizzando il costo iniziale di addestramento su query ripetute. L'approccio è particolarmente adatto per carichi di lavoro analitici in cui le query vengono eseguite migliaia di volte con piani subottimali.

Prospettive future

Il ricercatore suggerisce diverse direzioni future, tra cui il confronto con lo sweeping strutturato degli hint (come Bao), l'esplorazione della distillazione on-policy e il test dell'inversione delle tracce per riassunti di ragionamento. Il codice è open-source su GitHub, invitando alla replica e a ulteriori innovazioni.

Questo esperimento sottolinea una tendenza crescente: modelli piccoli e specializzati possono superare sia gli LLM generici che gli algoritmi tradizionali in compiti strettamente definiti, offrendo un percorso economico per l'ottimizzazione nella gestione dei database e oltre.