Performance Nebensache

Auch wenn für die Entwickler Performance-Optimierungen bei dieser Release keine Priorität hatten, wirkt sich so manche Änderungen sehr positiv aus. Durch Indizes mit »NOT-NULL« -Feldern untersucht die Version 9 im Gegensatz zu PostgreSQL 8.4 nur den Index, während 8.4 hierzu die Tabelle selbst filtern musste. Mit dem Entfernen unnötiger Join-Statements, beispielsweise wenn referenzierende IDs per »UNIQUE« ohnehin eindeutig sind, lässt sich in größeren Abfragen deutlich Zeit sparen.

Mit der effizienteren Neu-Implementation von »LISTEN« und »NOTIFY« bearbeitet der Master Events schneller, und dank der neuen Payload-Option kann eine lauschende Anwendung einen bis zu 8000 Byte langen String erhalten. Die Anweisung »VACUUM FULL« dupliziert nicht mehr jeden Datensatz einzeln, sondern erzeugt eine neue Tabelle und kopiert alle Einträge in einem Vorgang. Das spart je nach Datenmenge bis zu 60 Prozent der bisher benötigten Zeit.

Column-Trigger rufen automatisch Stored Procedures auf, sobald die Datenbank den Wert eines Feldes explizit aktualisiert, »WHEN« -Trigger prüfen dagegen datenbezogene Konditionen. Beide Funktionen vereinfachen viele Arbeiten innerhalb einer Applikation und reduzieren die Anzahl der auszuführenden Trigger, was die CPU entlastet sowie RAM und Festplatten-I/O spart.

Das folgende Bespiel ruft die Procedure »tr_update_status()« auf, sobald jemand einen Eintrag der Tabelle »tbl_user« im Feld »user_status« aktualisiert:

CREATE TRIGGER update_status BEFORE UPDATE OF user_status ON tbl_user FOR EACH ROW EXECUTE PROCEDURE tr_update_status();

Das lässt sich in vielen Fällen sinnvoll verwenden: Auf einem Asterisk-Server mit PostgreSQL-Backend zum Beispiel kann der Admin dies nutzen, um nach einem Telefonanruf eine Neuberechnung des Guthabens durchzuführen, ohne eine eigene komplexe Applikationslogik entwickeln zu müssen.

Mehr Sicherheit durch Token und Passwort-Policy

Mit der Möglichkeit, per Radius [4] zu authentifizieren, etwa durch Token, Cryptocard oder E-Token (Alladin) [5], macht PostgreSQL einen großen Schritt in Richtung hochsichere Umgebung. Mit der einfachen Konfiguration der Einträge »radiusserver« , »radiussecret« , »radiusport« und »radiusidentifier« ist die Anbindung auch schon erledigt. Das Modul »passwordcheck« erzwingt jedoch auch ohne Radius sichere Kennwörter.

Schon in älteren Versionen ließ sich PostgreSQL mit Erweiterungen wie Slony [6], Londiste [7] oder Pgpool-II [8] das Replizieren beibringen. So schnell sind diese Erweiterungen in vielen Installationen auch nicht zu ersetzen, weil sie häufig maßgeschneiderte Setups mitbringen. Die jetzt in Version 9 eingebaute Streaming Replication ist jedoch ein großer Schritt, da die meisten Admins keine komplexen Replikationsstrategien benötigen, wenn sie lediglich Daten von mehreren Orten im Netzwerk intensiv nutzen oder hochverfügbar machen wollen.