Seite 3: Blick auf die Performance

Wie üblich gibt es ein paar Änderungen, die auf eine bessere Performance abzielen. PostgreSQL 16 bringt zwar keine bahnbrechenden Neuerungen, aber einige sinnvolle Updates.

Page Level Freezing

Ein Pain Point in PostgreSQL ist VACUUM, das nach Änderungen in einer Tabelle die nicht mehr benötigten Zeilen aufräumt. Dank Page Level Freezing hat die Datenbank bessere Informationen über die Zahl der geänderten Speicherseiten (Pages) und das Alter der Änderungen. Damit kann das System entscheiden, ob Autovacuum eine Tabelle agressiv (eager) bearbeiten soll oder sichtbare Pages überspringt (lazy). Das soll in Datenbanken mit vielen Änderungen dafür sorgen, dass Autovacuum nicht irgendwann vor einem "Transaction ID Wraparound" steht und genau dann anfängt sämtliche Tabellen nacheinander zu scannen und so die Performance im Produktionsbetrieb zu reduzieren.

Schlauer sortiert

Bisher haben DISTINCT und ORDER BY intern immer das Ergebnis sortiert. Wenn PostgreSQL 16 einen vorsortierten Index findet, muss es das Zwischenergebnis nicht erneut sortieren.

Operationen, die viele Einträge in dieselbe partitionierte Tabelle kopieren, beispielsweise mit COPY oder Multi-row-INSERTs, profitieren von einem gecachten Tabellennamen. Da die Datenbank den Namen bei Bulk-Operationen zwischenspeichert, muss sie nicht jedes Mal aufwendig den Partitionsnamens auflösen. Die Optimierung funktioniert für Range- und List-, aber nicht für Hash-Partitionen.

Angepasste Fensterfunktionen

Für einige Window Functions ist es egal, ob ROWS oder RANGE verwendet wird. ROWS ist in der Regel schneller, aber RANGE der Default. Das betrifft unter anderem das häufig verwendete

row_number() OVER (ORDER BY spalte)

Intern können Fensterfunktionen das jetzt selbstständig auf RANGE umstellen. Das betrifft folgende Funktionen: row_number(), rank(), dense_rank(), percent_rank(), ntile(), cume_dist().

Die Änderung erfolgt transparent, sodass User von der verbesserten Performance profitieren.

Breaking Changes

Einige Änderungen führen zu Inkompatibilitäten. Die meisten der in den Release Notes vollständig aufgeführten Breaking Changes sollten die meisten Anwenderinnen und Anwender jedoch nicht betreffen. Die einschneidendsten Änderungen sind

• promote_trigger_file entfällt: Bisher hat die Konfigurationsoption den Pfad zu einer Datei angegeben, die einen Replica zu einem vollwertigen Datenbankserver promoted hat. Stattdessen kann man nun pg_ctl promote auf der Kommandozeile oder SELECT pg_promote() in der Datenbank verwenden.
• NULLs in Primärschlüsseln: Bisher war es möglich, Primärschlüssel als NULLS NOT DISTINCT zu definieren. Das bedeutet, dass jeder NULL-Wert gleich betrachtet wird. Für Primärschlüssel ist das nicht mehr erlaubt, aber weiterhin für Unique Indexes.
• postmaster-Link entfällt: Lange war der Datenbankserver sowohl unter dem Programmnamen postgres als auch postmaster verfügbar, wobei Letzteres ein Symlink auf Ersteres ist. Als Teil der Umstellung auf das Meson-Buildsystem ist der Link nun endgültig entfallen, nachdem dieser für viele Jahre bereits als überholt (deprecated) markiert war.

Upgrade auf Version 16

Vor einem Upgrade der Produktionsdatenbank sollte man sicherheitshalber das erste oder zweite Dot-Release (16.1 oder 16.2) abwarten. Bis dahin zeigt sich, ob es gravierende Probleme gibt. Üblicherweise spricht jedoch nichts dagegen, die neue Version in der Entwicklung zu testen.

Für das eigentliche Upgrade stehen mehrere Wege zur Verfügung:

• Dump & Restore ist üblicherweise der einfachste Weg: Man nutzt das pg_dump-Tool von PostgreSQL 16, um die alte Datenbank zu exportieren. Dabei kann man das Ergebnis in eine Datei oder direkt in die neue Datenbank schreiben. Das kann allerdings bei großen Datenbanken sehr lange dauern, und in der Zwischenzeit sind keine Änderungen erlaubt, da diese nicht mit migriert werden.
• Das pg_upgrade-Tool hilft dabei, eine ältere Datenbank direkt in die neue Datenbank zu migrieren. In der Voreinstellung kopiert es die Datendateien. Das erfordert ausreichend Speicherplatz und kostet Zeit für die Operationen auf der Festplatte. Mit der Option --link verlinkt pg_upgrade die Dateien stattdessen über Hardlinks. Das geht sehr schnell, erlaubt aber nach dem Start der neuen Version keine Rückkehr zur alten. Backups und ausreichende Tests sind also notwendig.
• Logical Replication erlaubt es, Datenbanken zwischen verschiedenen PostgreSQL-Versionen zu kopieren. Man setzt eine Replica mit der neuen Version auf, lässt sie alle Daten aus dem Primary kopieren. Anschließend schaltet man den Primary aus und befördert die Replica zum neuen primären System.

Blick nach vorn und zurück

Mit dem Release von PostgreSQL 16 verliert die 2018 erschienene Version 11 ihren bei der Datenbank üblichen fünfjährigen Support. Derweil hat die Arbeit an Version 17 bereits begonnen.

Weitere Details zu PostgreSQL 16 lassen sich der offiziellen Ankündigung entnehmen. Auf der Download-Seite finden sich ein Link zum Git-Repository mit dem Source-Code sowie Binaries für Linux, macOS, Windows. BSD und Solaris.

Andreas Scherbaum
arbeitet seit 1997 mit PostgreSQL. Er ist in diversen Projekten in der Community involviert, einer der Gründer und Direktoren von PostgreSQL Europe, hilft bei der Veranstaltung von Konferenzen und Meetups und hat irgendwann ein Buch über PostgreSQL geschrieben. Außerdem veröffentlicht er wöchentliche Interviews mit Mitgliedern der Community und schreibt einen Blog.

(rme)