The Pulse
Un modello da 4B ha ridotto del 44,7% la latenza delle query PostgreSQL
Rohan Bansal riferisce che un modello da 4B addestrato ha migliorato i piani di esecuzione di 113 query PostgreSQL con molti join, riducendo la latenza del 44,7% in un benchmark che lo confrontava con i piani predefiniti di PostgreSQL.
AI.info Team ·
Un modello linguistico da 4B addestrato ha ridotto la latenza del 44,7% su 113 query PostgreSQL con molti join, secondo un resoconto tecnico di Rohan Bansal. L’esperimento ha usato il fine-tuning supervisionato e l’apprendimento per rinforzo agentico per insegnare al modello a generare piani di esecuzione alternativi e a testarli confrontandoli con quelli predefiniti di PostgreSQL.
«Quello che segue è un resoconto dettagliato di un esperimento che ho condotto per esplorare questa domanda: un modello piccolo con pesi aperti può essere ulteriormente addestrato tramite fine-tuning supervisionato (SFT) e apprendimento per rinforzo agentico (RL) per produrre piani di esecuzione di Postgres migliori di quelli predefiniti di Postgres?»
Rohan Bansal, autore del resoconto
Bansal presenta il lavoro come un tentativo di affrontare una debolezza di lunga data nell’ottimizzazione delle query. PostgreSQL deve scegliere i piani basandosi su stime, invece di eseguire ogni possibile join durante la pianificazione. Una misurazione esatta vanificherebbe lo scopo di un ottimizzatore veloce, mentre l’ordinamento dei join diventa difficile all’aumentare del numero di tabelle.
L’esperimento tratta quindi l’ottimizzazione delle query come un problema di ricerca. Il modello genera una strategia candidata, la invia a PostgreSQL per misurarne le prestazioni e riceve un riscontro in base al fatto che la candidata sia più veloce del piano predefinito del database. L’obiettivo non è sostituire l’ottimizzatore di PostgreSQL durante l’esecuzione interattiva, ma trovare piani migliori per carichi di lavoro in cui le stesse query analitiche vengono eseguite ripetutamente.
Una baseline inizialmente inutilizzabile
Il benchmark ha usato 113 query con molti join dal Join Order Benchmark, basato su un database IMDb. Prima dell’addestramento, il modello da 4B ha ottenuto risultati scarsi quando è stato collegato al sistema di ottimizzazione delle query. Bansal riferisce che il modello non è riuscito a produrre un piano di esecuzione valido per 99 delle 113 query.
Solo un numero esiguo dei tentativi rimanenti ha prodotto candidate confrontabili con i piani predefiniti di PostgreSQL. Alcune candidate duplicavano il piano predefinito, mentre altre traiettorie fallivano durante la selezione o scadevano per timeout. I risultati hanno lasciato solo un insieme limitato di traiettorie utilizzabili per la valutazione iniziale.
Quella baseline ha fornito a Bansal un modo per misurare l’effetto dell’addestramento. Il fine-tuning supervisionato ha innanzitutto migliorato la capacità del modello di comunicare con il sistema agente. L’apprendimento per rinforzo agentico ha poi orientato il modello verso strategie che producevano piani misurati più veloci. L’addestramento ha usato anche dimostrazioni off-policy generate da un modello più grande, fornendo a quello più piccolo esempi di come esaminare una query e proporre modifiche.
Cosa ha cambiato il modello addestrato
Dopo l’addestramento, il modello ha esplorato regolarmente modifiche ai metodi di scansione, all’ordine dei join e all’esecuzione parallela. Ha anche privilegiato i join nested loop in alcuni casi, scelto scansioni dell’indice al posto di scansioni bitmap o sequenziali e modificato le impostazioni del pianificatore. Bansal individua tre fonti ricorrenti di miglioramento: riscrivere l’ordine dei join, correggere una singola scansione senza modificare l’albero dei join e abilitare l’esecuzione parallela.
Un esempio riguardava una query con una costosa scansione sequenziale e un filtro con perdita. Il modello ha individuato la scansione come un problema e ha forzato una scansione bitmap. Bansal riferisce che con il piano alternativo quella singola query è stata eseguita 90 volte più velocemente.
Il risultato complessivo del benchmark è stato meno estremo, ma comunque significativo. Valutando più candidate per ogni query e selezionando l’opzione migliore in base alle misurazioni, il sistema ha ottenuto un’accelerazione media geometrica di 1,81x sul carico di lavoro composto da 113 query. Bansal riferisce inoltre una riduzione della latenza del 44,7% sull’intero carico di lavoro.
Un sistema di ottimizzazione per i carichi di lavoro
I risultati si applicano ai carichi di lavoro analitici ripetuti, non alle richieste occasionali. Generare e misurare piani alternativi richiede ulteriore potenza di calcolo, quindi l’approccio ha più senso quando un piano può essere riutilizzato per molte esecuzioni della stessa query.
Bansal descrive il progetto come una dimostrazione del fatto che un piccolo modello con pesi aperti può apprendere un’attività di ottimizzazione specializzata quando le sue azioni sono collegate a un risultato misurabile. Il modello non deve sostituire il pianificatore di PostgreSQL in ogni situazione. Può invece cercare alternative offline, conservare i piani che funzionano meglio e applicare questi risultati a un carico di lavoro ricorrente.
Il resoconto presenta l’esperimento come un sistema di ricerca, non come una funzionalità di PostgreSQL pronta all’uso. Le sue prestazioni dipendono dal benchmark, dal processo di misurazione e dalla strategia usata per selezionare tra i piani candidati. Ciò nonostante, i risultati riportati mostrano che, dopo un addestramento mirato, un modello da 4B può migliorare le scelte predefinite di PostgreSQL per un insieme consistente di query con molti join.