Neuerungen in PostgreSQL 12

Für den großen Appetit

Die mit Version 10 eingeführte Methodik, nur noch die erste Stelle als Hauptversion zu führen, setzt sich mit PostgreSQL 12 fort. Die freie objektrelationale Datenbank unterstützt beim Verarbeiten großer Datenmengen und hält vor allem in den Bereichen Partitionierung, Indizierung und Optimizer einige Neuerungen bereit. Wir haben uns die wesentlichen Features genauer angeschaut.
Cloud-First-Strategien sind inzwischen die Regel und nicht mehr die Ausnahme und Workloads verlagern sich damit in die Cloud – auch Datenbanken. Dort geht es ... (mehr)

n Version 12 verbessert PostgreSQL die Effizienz und in einigen Punkten die Geschwindigkeit von B-tree-Indexen, dem standardmäßig verwendeten Indextyp. B-tree-Indexe speichern nun Gruppen von Doubletten in derselben Reihenfolge, wie diese auch physisch in den Tabellen gespeichert sind. Dadurch sinkt der Verwaltungsaufwand solcher Schlüsselwerte im Index signifikant. Einfügeoperationen profitieren hiervon, aber auch VACUUM, der den Speicherplatz nun effizienter verwalten kann. Im Idealfall reduziert sich der Speicherbedarf bei Indexen mit entsprechender Anzahl von solchen Gruppen von Doubletten deutlich.

Auch die Speicherrepräsentation von Btree- Indexen, die mehrere Spalten indizieren, wurde verbessert, sodass auch in diesem Fall entsprechende Indexe merklich weniger Speicherplatz verwenden können. Da diese Änderungen die Struktur von Btree- Indexen beeinflussen, müssen Instanzen, die mit "pg_upgrade" migriert wurden, auf jeden Fall ein REINDEX durchführen. Dadurch wird die physische Repräsentation des entsprechenden Index neu angelegt. Wenn der Administrator B-tree-Indexe einfach beibehält, kann er die genannten Optimierungen nicht anwenden. Die Indexe lassen sich jedoch einfach weiter benutzen. Durch verbessertes Sperrverhalten steigert sich auch die Geschwindigkeit bei vielen nebenläufigen INSERT-Operationen, die auch einen B-tree-Index aktualisieren.

Just-In-Time Compilation (JIT) ist in der aktuellen Version standardmäßig aktiv. Bei bestimmten Aggregaten oder SQLAusdrücken kann PostgreSQL diese je nach Komplexität der Abfrage direkt in Maschinencode kompilieren und ausführen. Das Feature ist seit PostgreSQL 10 verfügbar, war seither jedoch im Auslieferungszustand deaktiviert.

Schnellerer Durchsatz mit Autovacuum

In dem neuen Release ist "autovacuum_vacuum_ cost_delay" nun auf zwei Millisekunden konfiguriert, was für schnelleren Durchsatz von entsprechenden VACUUM- Prozessen sorgt. Die maximale Leserate steigt dadurch auf knapp 78 MByte/s, die Schreibrate auf 39 MByte/s. Das entspricht einer deutlichen Steigerung gegenüber 7,8 MByte/s respektive 3,9 MByte/s bei den Vorgängerversionen. Allerdings waren vor allem große oder schreibintensive PostgreSQL-Datenbanken auch in der Vergangenheit gut beraten, die anvisierten Lese- und Schreibraten von autovacuum entsprechend anzupassen.

Kurze Wartezeiten mit REINDEX CONCURRENTLY

Ein lang erwartetes Feature ist die Möglichkeit, REINDEX ohne Aussperren von INSERT-, UPDATE- und DELETE-Anweisungen (DML) auszuführen. Wenn es darum geht, nach einem "pg_upgrade" auf PostgreSQL 12 ohne längere Wartezeiten auf die neue B-tree-Version zu wechseln, ist das eine nützliche Funktion. Hierzu erhält REINDEX die bereits seit längerem bei CREATE INDEX verfügbare Option CONCURRENTLY. Es sei an dieser Stelle angemerkt, dass bisher nur das CREATE INDEX-Kommando mehrere Workerprozesse für den Aufbau eines Indexes unterstützt.

Bild 1: Optimierter Ausführungsplan einer CTE-Anweisung mittels Inlining.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023