Vier Postgres-Container laufen auf einem gewöhnlichen Schreibtisch, daneben ein Laptop, der die Last verteilt. Auf einem gemieteten Knoten mit zwei H100-Karten arbeitet ein vLLM-Server, der Token für Token Query-Pläne ausgibt, während ein Trainer-Prozess daneben dieselben Gewichte fortschreibt. Rohan Bansal hat dieses Setup für ein einziges Experiment aufgebaut: Er wollte wissen, ob sich ein kleines Open-Weights-Modell mit 4 Milliarden Parametern so trainieren lässt, dass es bessere Pläne für Postgres erzeugt als der eingebaute Optimierer. Die kurze Antwort lautet ja. Über 113 join-lastige Abfragen aus dem Join-Order-Benchmark erreichte das Modell eine durchschnittliche Latenzreduktion von 44,7 Prozent, in einzelnen Fällen bis zu 81 Prozent. Für 99 dieser Abfragen war das Basismodell anfangs nicht einmal in der Lage, einen gültigen Plan zu erzeugen.
Warum Postgres bei der Join-Reihenfolge raten muss
Was da trainiert wurde, versteht man besser, wenn man sich ansieht, was ein Query Optimizer eigentlich tut. Eine Abfrage auf dem IMDb-Datensatz: Welche japanischen Firmen haben in den 2000er Jahren die meisten Titel veröffentlicht? Drei Tabellen sind beteiligt, Firmen, Titel, und die Zuordnung zwischen beiden. Der Planer muss entscheiden, in welcher Reihenfolge er diese Tabellen zusammenführt. Diese Entscheidung ist nicht Geschmackssache, sie entscheidet über Sekunden. Wer zuerst die japanischen Firmen herausfiltert, schleust womöglich hunderttausend Zeilen in den nächsten Schritt. Wer zuerst nach Jahrzehnt filtert, vielleicht vierhunderttausend. Der Unterschied ist der Faktor vier, und solche Faktoren summieren sich über einen ganzen Plan.
Das Problem: Postgres kann nicht nachzählen. Um zu wissen, wie viele Zeilen ein Zwischenschritt produziert, müsste die Datenbank den Join tatsächlich ausführen, und damit wäre der Optimierer langsamer als die Abfrage selbst. Stattdessen greift der Planer auf Statistiken zu, auf häufigste Werte pro Spalte und Histogramme für den Rest, und extrapoliert. Bei Joins wird es heikel: Über die Verteilung der Zeilen zwischen zwei Tabellen weiß Postgres nichts und nimmt deshalb Gleichverteilung an. Diese Annahme ist als Heuristik vernünftig und als Realität oft grotesk falsch. Wenn fünf Prozent der Firmen japanisch sind, aber diese fünf Prozent die Hälfte aller Filme produziert haben, bricht die Schätzung um den Faktor zehn ein. Eine einzige schlechte Schätzung früh im Baum zieht alle folgenden Schätzungen mit. Deshalb wird die Frage nach der Qualität von Query Optimizers seit einem Jahrzehnt immer wieder gestellt und hat immer noch keine befriedigende Antwort.
Vier Arten von Scan, drei Join-Verfahren, und plötzlich 4.608 Möglichkeiten
Die Reihenfolge der Tabellen ist nur ein Teil des Suchraums. Jeder Join kann als Hash Join, Merge Join oder Nested Loop ausgeführt werden. Jede Tabelle lässt sich sequenziell lesen, über einen Index, über einen Index-only Scan oder über eine Bitmap. Zählt man all das für die drei Tabellen der Beispielabfrage zusammen, kommt man auf 4.608 verschiedene Ausführungspläne für eine einzige Abfrage. Das ist noch eine Untertreibung, denn Parallelität, Aggregationsvarianten und Sortierverfahren sind nicht mitgerechnet, und mit jeder weiteren Tabelle wächst der Raum kombinatorisch weiter. Dass Join Ordering im Allgemeinen NP-schwer ist, ist keine akademische Fußnote, sondern der Grund, warum Postgres ab zwölf Joins von dynamischer Programmierung auf einen genetischen Algorithmus umschaltet.
Hier liegt die eigentliche Beobachtung des Experiments. Einen Plan zu finden ist schwer. Zu prüfen, ob ein gefundener Plan gut ist, ist dagegen trivial: Man führt ihn aus und stoppt die Zeit. Das ist die Konstellation, in der Sprachmodell-Training zuverlässig funktioniert. Es gibt eine einzige Achse, auf die man optimieren kann, nämlich die Ausführungszeit, und die lässt sich messen. Damit wird aus einem Optimierungsproblem ein Lernproblem, und aus einem Lernproblem eine Frage des Belohnungssignals. Wer Postgres Query-Optimierung mit Reinforcement Learning verbessern will, braucht nichts weiter als eine ehrliche Stoppuhr und genügend Geduld.
Wie man einen Elefanten lenkt: pg_hint_plan als Steuerhebel
Das Modell erzeugt die Pläne nicht selbst, es schreibt Hinweise. Die Erweiterung pg_hint_plan erlaubt es, in einem normalen SQL-Kommentar mit vorangestelltem Pluszeichen Anweisungen zu hinterlegen, die Postgres ignoriert und die Erweiterung auswertet. Ein Hint wie HashJoin oder SeqScan zwingt den Planer, einen bestimmten Join-Algorithmus oder eine bestimmte Zugriffsmethode zu verwenden. Damit bewegt sich das Modell in einem festen Rahmen: Es gibt eine begrenzte, dokumentierte Sprache aus, und Postgres baut daraus einen gültigen Plan. Das ist der entscheidende Trick, denn das Modell muss nicht die gesamte Komplexität eines Planers replizieren. Es muss nur lernen, wann welcher Hebel sinnvoll ist.
Bansal beschreibt zwei Ansätze und verwirft den ersten ausdrücklich. Die Idee, dem Modell exakt dieselben Informationen zu geben wie dem Planer und damit einen besseren Kardinalitätsschätzer zu bauen, hätte bedeutet, gegen Jahrzehnte Forschung anzutreten, und die Inferenzlatenz allein wäre teurer als der gesamte Postgres-Optimierer. Der zweite Ansatz setzt dort an, wo der Planer schwach ist: nicht bei der Genauigkeit der Schätzung, sondern bei der Fähigkeit, aus einer schlechten Schätzung trotzdem einen brauchbaren Plan zu machen. Das Modell lernt Muster über Tabellen, Prädikate und Filterstärken hinweg und schlägt Reihenfolgen vor, die das Kostenmodell des Planers nie wählen würde, weil sie nach dessen Rechnung teurer sind, in der Realität aber schneller laufen.
Supervised Fine-Tuning als Startrampe, GRPO als Trainingslager
Der Trainingsweg verlief in zwei Stufen. Zuerst kam Supervised Fine-Tuning für Query-Pläne ins Spiel: Das 4B-Modell lernte an rund fünfhundert Agenten-Trajektorien eines großen Modells, also an konkreten Abläufen, in denen ein Agent eine Abfrage analysiert, Kandidaten-Pläne erwogen und sich für einen entschieden hat. Diese Off-Policy-Destillation ist der Grund, warum das Modell danach überhaupt Pläne für Abfragen erzeugen konnte, an denen es vorher gescheitert war. Ohne diesen Schritt hätte das Reinforcement Learning auf einem Fundament gestanden, das für 99 der 113 Testabfragen schlicht keine Ausgabe produzierte.
Danach übernahm Reinforcement Learning, genauer eine eigens angepasste Variante von GRPO. GRPO für Query-Optimierung einzusetzen klingt naheliegend, bringt aber ein Problem mit: Die Belohnung ist die Laufzeit, und Laufzeit ist verrauscht. Cache-Zustand, Container-Nachbarn, Hintergrundlast, all das verschiebt Messwerte um Prozentpunkte, die über Sieg und Niederlage entscheiden. Bansal musste deshalb nicht nur ein Modell trainieren, sondern auch eine Messumgebung bauen, die dieses Rauschen klein hält. Die GRPO-Variante wurde so angepasst, dass sie Rollouts in einer inhärent unsauberen Umgebung fair gegeneinander bewertet. Wer ein 4B-Modell für schnellere Postgres-Query-Pläne trainieren will, lernt hier, dass die halbe Arbeit im Messen steckt.
Vier Container auf dem Schreibtisch und ein gemieteter Doppel-H100-Knoten
Die Infrastruktur ist unspektakulär, und gerade deshalb lehrreich. Auf der einen Seite stand ein gemieteter Knoten mit zwei H100-Karten, auf dem vLLM die Rollouts generierte und der Trainer parallel die Gewichte aktualisierte. Auf der anderen Seite liefen vier Postgres-Container auf einem Schreibtisch. Diese Trennung hatte einen Zweck: Sie erlaubte es, die Datenbanklast physisch vom Modelltraining zu entkoppeln und zugleich die Linux-Page-Cache-Konkurrenz zwischen den Containern zu kontrollieren, die sonst jede Messung unbrauchbar macht. Wenn zwei Postgres-Instanzen um denselben Cache konkurrieren, misst man nicht mehr den Plan, sondern den Zufall.
Über 113 join-lastige Abfragen ergab sich eine durchschnittliche Reduktion der Latenz um 44,7 Prozent gegenüber dem Postgres-Standard, in der Spitze bis zu 81 Prozent. Wichtiger als die Spitzenwerte ist die Verteilung: Das Modell gewinnt nicht nur bei einigen exotischen Abfragen, bei denen die Gleichverteilungsannahme spektakulär scheitert, sondern breit über den Benchmark hinweg. Und es verliert nicht, indem es ungültige Pläne produziert, denn die Hint-Sprache lässt das gar nicht zu. Es gewinnt oder es gewinnt weniger.
Was 44,7 Prozent konkret bedeuten, und was nicht
Für dich als Betreiber einer Datenbank heißt das nicht, dass du morgen ein Modell neben deinen Postgres-Server stellst. Der Versuchsaufbau ist ein Benchmark, kein Produktivsystem, und der Join-Order-Benchmark ist bewusst so gebaut, dass er die Schwächen klassischer Kardinalitätsschätzung bloßlegt. Die Query-Pläne sind schneller als der Postgres-Default, weil der Default an einer bekannten, seit zehn Jahren dokumentierten Stelle schwach ist, nicht weil das Modell zaubern kann. Wer aus dem Experiment einen Trend ableiten will, sollte ihn so lesen: Der Optimierer ist ein gelöst geglaubtes Problem, das keines ist, und Sprachmodelle sind inzwischen gut genug, um in engen, klar bewertbaren Domänen als Korrektiv aufzutreten.
Interessant ist vor allem die Methodik. Ein 4B-Modell, zwei gemietete GPUs, vier Container und eine etablierte Erweiterung, die es seit Jahren gibt. Kein neuer Datenbank-Kern, keine Änderung am Cost Model von Postgres, kein Eingriff in den Quellcode. Der Steuerhebel war von Anfang an da, es fehlte nur jemand, der lernt, ihn zu bedienen. Fortschritt entsteht hier nicht durch einen radikalen Umbau, sondern durch das gezielte Kombinieren vorhandener Teile. Wer selbst mit Postgres Query-Optimierung experimentiert, findet in diesem Aufbau eine Blaupause, die sich mit überschaubarem Budget nachbauen lässt. Die Frage ist dann nicht mehr, ob es funktioniert, sondern nur noch, für welche deiner eigenen Abfragen es sich lohnt.
Quelle: rohanbansal.com
