Die Neuerungen in PostgreSQL 11
Mehrgleisig
Mitte Oktober erschien PostgreSQL 11. Wie es sich für eine Major Release gehört, bringt sie viele neue Funktionen und Verbesserungen bestehender Features.
Der Herbst bringt nicht nur fallende Blätter und längere Nächte mit sich, sondern – wie es die Tradition will – auch eine neue Version einer der am weitesten verbreiteten Open-Source-Datenbanken. Seit einigen Wochen ist PostgreSQL 11 allgemein verfügbar.
Gerade rechtzeitig
Eins der herausragendsten Features von PostgreSQL 11, das die Datenbank auch von ihren Mitbewerbern absetzt, ist die Just-in-Time-Kompilierung (JIT). Die Datenbank übersetzt dabei Teile von Anfragen unmittelbar vor der Ausführung (just in time) in Maschinencode, um sie performanter zu machen. Das klingt gut, hat jedoch einen Haken: Die Kompilierung und gegebenenfalls die anschließende Optimierung kostet natürlich auch Zeit, sodass sich das Verfahren nur für lang laufende, meist analytische Leseanfragen lohnt, die außerdem CPU-bound sind. Da JIT für kurze Transaktionen nur ungewollten Overhead bedeutet, ist dieses Feature so in den Planner der Datenbank integriert, dass es überhaupt nur zum Tragen kommt, wenn die vom Optimizer geschätzten Kosten einer Anfrage ein konfigurierbares Limit übersteigen. Das Kommando EXPLAIN gibt den Ausführungsplan inklusive Kosten aus und zeigt auch, ob die JIT-Kompilierung zum Einsatz kommt. Es gibt noch zwei weitere Kostenlimits, die in der Folge bestimmen, ob Funktionen inline in den Code eingebaut werden und ob der verwendete LLVM-Compiler auch optimieren soll (was beides zusätzlich Zeit in Anspruch nimmt).
Verwendung findet die JIT-Kompilierung bei Ausdrücken in der SELECT-Liste und in WHERE-Klauseln, bei Aggregation sowie beim „Tuple Deforming“, also während der Transformation der Zeilen von ihrem On-Disk- in ihr In-Memory-Format. Die Postgres-Spezialisten von Citus Data haben die neue JIT-Kompilierung bereits in einer Pre-Release von PostgreSQL 11 mit der ersten Query des TPC-H Benchmarks getestet (siehe ix.de/ix1812060). Dort zeigte sie etwa 30 Prozent schnellere Antwortzeiten. Citus vergleicht allerdings PostgreSQL 10 ohne JIT mit PostgreSQL 11 mit JIT. In Tests der iX, in denen PostgreSQL 11 ohne JIT gegen Version 11 mit JIT antrat, fiel der JIT-Geschwindigkeitsvorteil deutlich geringer aus (30 s zu 35 s).
Parallel gestrickt
Während der Mitbewerber MySQL einzelne Abfragen nur sequenziell bearbeiten kann und somit immer nur einen einzigen CPU-Kern pro Query benutzt, verfügt PostgreSQL schon seit Version 9.6 über die Möglichkeit, einzelne Bestandteile einer Abfrage mehrgleisig in mehreren Prozessen auszuführen und so zu beschleunigen. Zwar ist dies nicht bei allen Abfragen sinnvoll möglich, doch haben sich die Entwickler auch auf diesem Gebiet einiges für die neue Version einfallen lassen.
So war es bisher nicht möglich, Hash-Joins verteilt abzuarbeiten, da die im ersten Schritt erstellte Hash Table auch immer nur dem ersten Prozess zur Verfügung stand. Für die Version 11 wurde diese Hash Table ins Shared Memory übernommen, sodass auch hier nun eine parallele Verarbeitung möglich ist.
Partition Scans und sequenzielle Scans ließen sich bisher schon parallel ausführen. Hier hat sich die Performance durch verschiedene Optimierungen aber weiter verbessert.
In der Praxis hängt es stark von der konkreten Abfrage ab, ob eine Parallelisierung Sinn macht oder überhaupt möglich ist. Ein Sonderfall sind jedoch mittels UNION verbundene SELECT-Querys: Die einzelnen Sub-Querys sind voneinander unabhängig und selbst wenn sich diese nicht in sich parallelisieren lassen, führt die Datenbank in der neuen Version die SELECTs gleichzeitig auf verschiedenen CPUs aus und fügt die Ergebnisse anschließend zusammen.