Entwicklung eines neuen JIT-Compilers für PostgreSQL

(pinaraf.info)

4 Punkte von GN⁺ 2024-03-20 | Noch keine Kommentare. | Auf WhatsApp teilen

Nachdem in Python 3.13 eine neue Methodik zum Aufbau eines JIT-Compilers (copy-patch) eingeführt wurde, fiel die Entscheidung, diese auf PostgreSQL anzuwenden.
Vorgestellt wird ein neuer Ansatz namens pg-copyjit, der die Geschwindigkeit des PostgreSQL-Servers verbessern soll.
Der gesamte Code ist experimentell und sollte vor dem Einsatz in einer produktiven Umgebung von Fachleuten geprüft werden.

Anfangs gab es kein JIT, dann kam der LLVM-JIT-Compiler

In PostgreSQL wurde JIT-Kompilierung mit LLVM eingeführt, doch LLVM hat einige Eigenschaften, die für JIT-Kompilierung nicht ideal sind.
LLVM-Optimierungen sind kostspielig, und ohne sie kann die Kompilierung selbst sinnlos sein.
Die Kostenschätzung von PostgreSQL für Abfragen steht nicht in direktem Zusammenhang mit der tatsächlichen Ausführungszeit, weshalb viele Nutzer den JIT-Compiler deaktivieren.

Es besteht die Notwendigkeit, möglichst schnell schnellen und ausreichend guten Code zu erzeugen.
Der copy-patch-Ansatz erzeugt Code schnell mithilfe von in C geschriebenen Stencils (Template-Funktionen).
Die Stencils werden in einen neuen Speicherbereich kopiert, Lücken werden gefüllt, und anschließend kann direkt in die „kompilierte“ Funktion gesprungen werden.

Der Aufbau einer neuen JIT-Engine für PostgreSQL ist nicht besonders schwierig; vorgeschlagen wird, LLVM zu einem Plugin zu machen, damit andere JIT-Compiler eingeführt werden können.
Es reicht aus, eine einzelne Funktion _PG_jit_provider_init bereitzustellen und drei Callbacks zu initialisieren: compile_expr, release_context und reset_after_error.
Der copy-patch-Algorithmus ist einfach: Für jeden Opcode wird der passende Stencil gesucht und hinzugefügt, anschließend werden die benötigten Werte in die Lücken eingesetzt.

Es funktioniert mit PostgreSQL 16 und unterstützt derzeit nur AMD64.
Die Codegenerierung ist in wenigen hundert Mikrosekunden abgeschlossen und kann daher auch bei kurzen Abfragen genutzt werden.
Zwar gibt es noch keine Optimierungsphase, aber im Vergleich zum Interpreter ist bereits eine bessere Performance zu erkennen.
Es sind noch nicht viele Opcodes implementiert; bei Abfragen, die noch nicht unterstützt werden, springt stattdessen der PostgreSQL-Interpreter ein.

Dies befindet sich im Proof-of-Concept-Stadium; ein einfacher Build- oder Packaging-Prozess ist derzeit noch kein Thema.
Der Fokus liegt darauf, mehr Opcodes zu implementieren und Optimierungsmöglichkeiten zu finden.
Auch die Portierung auf andere Architekturen wird ernsthaft in Betracht gezogen.

Dank gilt dem aktuellen Arbeitgeber Entr’ouvert, dessen Kolleginnen und Kollegen Zeit für dieses Projekt ermöglicht haben.
Ebenfalls bedankt wird sich bei den DBA-Freunden, verbunden mit der Empfehlung, PoWA auszuprobieren.

Dieser Artikel stellt einen neuen Ansatz zur Verbesserung der Performance des PostgreSQL-Datenbankservers vor. Das könnte für Datenbankadministratoren und Entwickler interessant sein.
Bevor experimenteller Code in produktiven Umgebungen eingesetzt wird, sind gründliche Tests und Validierung erforderlich. So lassen sich Risiken wie Datenverlust oder Ausfallzeiten vermeiden.
Im Vergleich zu bestehenden JIT-Compilern wie LLVM kann der copy-patch-Ansatz eine schnellere Codegenerierung ermöglichen und dadurch auch für kurze Abfragen nützlich sein.
Sollte diese Technik in der PostgreSQL-Community breite Akzeptanz finden, könnte sie zusammen mit der Unterstützung weiterer Architekturen ein neues Kapitel bei der Optimierung der Datenbank-Performance aufschlagen.
Kritisch betrachtet steht das Projekt noch am Anfang, und es braucht weitere Forschung und Entwicklung, um zu zeigen, wie sich die tatsächlichen Performancegewinne in produktiven Umgebungen auswirken.