Seite 2: Beliebige Werte

Ein weiteres aus dem SQL-Standard in PostgreSQL 16 übernommene Feature ist ANY_VALUE. Es dient in Grouping-Anfragen dazu, einen beliebigen Wert aus der angegebenen Spalte zu extrahieren. Ohne dieses Aggregat muss man spezifizieren, welchen Wert man gruppieren möchte. Das sollte Migrationen von anderen Datenbanken wie MySQL vereinfachen, die SQL-Queries mit nicht aggregierten Spalten aus Bequemlichkeit und Geschwindigkeitsgründen erlaubt haben. In PostgreSQL muss man weiterhin die Spalte aggregieren, aber ANY_VALUE erlaubt die Auswahl eines beliebigen Wertes.

SELECT nutzerid, count(*), ANY_VALUE(nutzername)
  FROM nutzer GROUP BY nutzerid;

Logical Replication mit verbesserter Sicherheit

PostgreSQL führt die neue Rolle pg_create_subscription ein, die Subscriptions für Logical Replication erzeugen kann. Damit ist es nicht mehr erforderlich, einen Superuser Account für die Replikation zu verwenden.

GRANT pg_create_subscription TO replica_user;​

Die DML-Befehle (Data Manipulation Language) INSERT, UPDATE und DELETE sowie alle SELECT-Operationen in einer logischen Replikation laufen jetzt unter den Rechten des Eigentümers der Tabelle. Das vermeidet Schwachstellen, wenn die Rolle für die Replikation zu viele Rechte besitzt. Wer das vorherige Verhalten beibehalten möchte, muss die Option run_as_owner=true setzen.

Verspätete JSON-Neuerungen

Kurz vor dem Release von PostgreSQL 15 hat die Community eine ganze Reihe neuer Funktionen für JSON wieder aus dem Release entfernt, weil es kurzfristig Qualitätsprobleme mit dem Code gab. Version 16 bringt die Neuerungen nun mit.

JSON-Konstruktoren sind im SQL Standard definiert und jetzt verfügbar: JSON_OBJECT, JSON_OBJECTAGG, JSON_ARRAY und JSON_ARRAYAGG.

Konstruktoren wie to_json(), row_to_json(), json_build_array() oder json_build_object() existieren seit geraumer Zeit. Da sie jedoch PostgreSQL-spezifisch sind, lassen sie sich nicht einfach auf andere Datenbanken portieren. Die neuen SQL-Standard-Konstruktoren ermöglichen portablen Code.

SELECT JSON_OBJECT('key': 'value');
{"key": "value"}

Ebenfalls neu sind die JSON-Prädikate IS JSON, IS JSON ARRAY, IS JSON OBJECT und IS JSON SCALAR. Mit ihnen lässt sich unter anderem prüfen, ob ein Element ein JSON-Objekt ist:

SELECT '{}'::JSONB IS JSON OBJECT;

Begrenzter Puffer

Die Option BUFFER_USAGE_LIMIT für VACUUM sorgt dafür, dass ein VACUUM nicht zu viele Speicherseiten im Shared Buffer verwendet. Die Konfigurationsoption vacuum_buffer_usage_limit setzt die Voreinstellung dafür und ist standardmäßig auf 256 kB gesetzt.

VACUUM (BUFFER_USAGE_LIMIT '50MB');​

Ein manuelles VACUUM in PostgreSQL ist nicht limitiert und versucht die angegebenen Tabellen so schnell wie möglich zu bearbeiten. Dafür wird die Datenbank alle notwendigen Speicherseiten in den Shared Buffers Bereich laden und dafür gegebenenfalls vorhandene Pages mit Produktionsdaten entfernen. Das verringert die Performance der Datenbank, da sie die Produktionsdaten später wieder laden muss.

Statistiken für Scans und Storage-Typen

Die pg_stat_*_tables-Views zeigen neuerdings nicht nur an, wie oft PostgreSQL eine Tabelle sequenziell oder per Index gescannt hat, sondern speichern zusätzlich den Zeitpunkt des letzten Scans. Wenn sich beispielsweise Probleme mit einem EXPLAIN-Plan für eine langsam laufende Query ergeben, ist der Zeitpunkt des letzten kompletten Scans der Tabelle ein guter Anhaltspunkt für weitere Recherchen.

Bisher war es notwendig, erst eine Tabelle zu erstellen und dann den Storage-Typ einer Spalte zu ändern. In Version 16 kann man den Storage-Typ direkt beim Erstellen angeben. Viele werden sich fragen, warum es das nicht schon immer gab.

CREATE TABLE benutzer (
  beschreibung TEXT STORAGE EXTERNAL
);

Flexiblere Zahlendarstellung

Nicht-dezimale Zahlen dürfen jetzt in verschiedenen Formaten – binär, oktal oder hexadezimal – angegeben werden:

SELECT 0b100, 0o10, 0x10;
 4 | 8 | 16

Außerdem ist zur besseren Lesbarkeit neuerdings die Unterteilung mit Unterstrichen erlaubt:

SELECT 2_147_483_647;

Schlankere Backups

Das Tool pg_dump Tool erlaubt nun die Angabe eines Kompressionsalgorithmus und der Kompressionsrate. Welche Algorithmen sich nutzen lassen, hängt davon ab, mit welchen Libraries PostgreSQL kompiliert wurde.

Folgender Befehl verwendet lz4 statt gzip mit der höchsten verfügbaren Kompressionsrate 9:

pg_dump -Z lz4:9