PostgreSQL 8.2
Was ist neu?

Was ist neu in PostgreSQL 8.2?

Warm-Standby-Datenbanken

Siehe hierzu: Replikation - Lösungen für PostgreSQL

Online-Index-Builds

ohne CONCURRENTLY (bis Version 8.2)

Während der Erzeugung eines Index sperrt PostgreSQL Schreibzugriffe für die betroffene Tabelle, bis der Index (in einem einzigen table-scan) erzeugt ist. Lesezugriffe sind immer möglich, aber INSERT, DELETE oder UPDATE-Operationen für diese Tabelle müssen warten, bis die Erstellung des Index abgeschlossen ist. In stark frequentierten Datenbanken oder bei grossen Tabellen kann dies zu nicht vertretbaren Wartezeiten führen, weswegen man solche Aufgaben oft in zugriffsschwache Zeiträume verlegen musste.

CONCURRENTLY

Mit dieser Option kann PostgreSQL Indizes erzeugen, ohne Schreibsperren auf die indizierte Tabelle zu legen. Konkurrierende INSERTs, UPDATEs und DELETEs sind während der Indexerstellung möglich. Diese Art der Indexerstellung hat aber ihren Preis: Es sind zwei table-scans nötig und ausserdem muss erst gewartet werden, bis alle offenen Transaktionen beendet sind. Deshalb erfordert diese Art mehr Rechnerlast und dauert wesentlich länger, ist aber in bestehenden Produktivumgebungen nützlich, wenn neue Indizes zugefügt werden sollen, ohne Schreibzugriffe zu sperren. Die zusätzliche Rechnerlast und I/O können andere Operationen verlangsamen.

Wenn UNIQUE-Indizes CONCURRENTLY erzeugt werden, wird der UNIQUE-Constraint bereits beim zweiten table-scan von anderen Transaktionen überwacht. Entsprechende Fehlermeldungen können deshalb in diesen Transaktionen auftreten, bevor der Index vollständig erzeugt ist oder wenn die Erzeugung fehlschlug. Auch nach einem solchen Fehlschlag ist der UNIQUE-Constraint wirksam. (DROP und neu erzeugen)

Auch funktionale und partielle Indizes können konkurrierend erzeugt werden. Allerdings können nicht mehrere konkurrierende Indizes für eine Tabelle parallel erzeugt werden, was bei normalen Indizes möglich ist. CREATE INDEX CONCURRENTLY ist immerhalb von Transaktionen nicht erlaubt.

GIN – Generalized Inverted Index

GIN bezeichnet eine Index-Struktur, die eine Menge von (key, dokumentenliste) - Paaren speichert, wobei dokumentenliste eine Menge von Datensätzen bezeichnet, die key in einem besimmten Feld enthalten. Invertiert meint, dass nicht etwa ein Primärschlüssel im Index gespeichert ist, um auf einen Datensatz zu verweisen, sondern Begriffe, die in dem Feld selbst enthalten sind. (siehe: http://en.wikipedia.org/wiki/Inverted_index)

Das Ziel ist, eine hoch anpassbare Volltextsuche für PostgreSQL zu implementieren. Erste Ergebnisse, wie GIN sich bei einer Volltextsuche mi Tsearch2 auswirkt, können Sie auf der Seite GIN performance nachlesen.

Damit GIN für bestimmte Datentypen eingesetzt werden kann, müssen benutzerdefinierte Zugriffsmethoden für diese Datentypen implementiert werden. Die Prototypen dieser Zugriffsmethoden sind in der GIN-Schnittstelle vorgegeben.

Advisory locks

Abgesehen von den Sperren, die bestimmte Kommandos verursachen (siehe: PostgreSQL Locks), können diese Sperren in PostgreSQL auch explizit mit LOCK table ... gesetzt werden.

Advisory Locks bieten eine weitere Möglichkeit, Sperren zu setzen, die vom System her nicht erforderlich sind. Es liegt in der Verantwortung einer Anwendung/eines Anwenders, die Sperren korrekt zu setzen und wieder aufzuheben.

Advisory locks werden solange gehalten, bis sie explizit freigegeben werden oder die Datenbanksitzung endet. Im Gegensatz zu allen anderen Sperren, ignorieren sie die Regeln bei der Verarbeitung von Transaktionen, dh, wenn ein advisory lock innerhalb einer Transaktion angefordert wird und die Transaktion wird zurückgerollt, bleibt die Sperre bestehen.

Dieselbe Sperre kann von dem Eigentümerprozess mehrmals angefordert werden, dann muss es für jede lock-Funktion auch eine unlock-Funktion geben, bevor die Sperre ganz aufgehoben werden kann. Falls eine Datenbanksitzung bereits eine Sperre besitzt, werden zusätzliche Sperranforderungen immer bedient, auch wenn andere Sitzungen auf die Freigabe warten.

Zur Verwaltung von advisory locks (lock und unlock) stehen vordefinierte Funktionen zur Verfügung. Eine komplette Liste aller aktuellen Sperren, auch der advisory locks, bietet der View pg_locks.

Full Disjunctions (pgfoundry-Projekt)

Die Tupelmengen aller Tabellen, die in gemeinsamen Attributwerten übereinstimmen, werden miteinander verknüpft, so dass

• die maximal verfügbare Informationsmenge zurückgegeben wird
• die Beziehungen der beteiligten Tabellen untereinander erhalten bleiben (da jedes Tupel mindestens in einem Ergebnistupel enthalten ist)
• Duplikate eliminiert werden

Ziel: Alle verwandten Informationen, und nur diese, sollen ohne Informationsverlust abgefragt werden.

Motivation: Wenn die Einträge in den Tabellen unvollständig sind (wenn Spalten NULLwerte enthalten), verlieren NATURAL JOINs Informationen, weil nur die Datensätze zurückgegeben werden, deren Werte in den Spalten übereinstimmen und dieses Zwischenergebnis mit der nächsten Tabelle verknüpft wird. Full disjunctions erhalten diese Informationen und sind deshalb nützlich zur Abfrage heterogener Datenquellen, wie zB Webinhalte, bei denen nicht vorausgesetzt werden kann, dass alle Spalten Werte enthalten. Ein Beispiel unter: http://www.technion.ac.il/~tzahi/soc.html.

Selektiver pg_dump

Ab PostgreSQL 8.2 ist es möglich, einzele Datenbankschemen zu dumpen oder auch bestimmte Datenbankschemen von einem Dump auszuschliessen.

macht einen Dump das angegebenen Schemas. Mehrere Schemen können durch wiederholte Angabe von -n schema gedumpt werden. Standardmässig werden mit -n keine Large Objects gedumpt, diese können mit der Option --blobs eingeschlossen werden.

Mit dieser Option können Schemen vom Dump ausgeschlossen werden. Der Schemaname wird als pattern interpretiert und jeder Schemaname, der auf das pattern passt, wird ausgeschlossen.

Ist -n und -N angegeben, werden die Schemen gedumpt, die mindestens auf ein -n-pattern passen aber auf kein -N-pattern.

Neue Option für psql

Hat diese Variable einen Wert > 0, werden die Ergebnisse einer SELECT-Abfrage geholt und in Blöcken mit x Zeilen dargestellt, anstatt zuerst alle Zeilen zu holen und dann am Stück auszugeben wie in der Standardeinstellung. Dadurch wird nur eine begrenzte Menge des Speichers benutzt, egal wie gross die Ergebnismenge ist. Es kann passieren, dass eine Abfrage auch dann noch abbrechen kann, nachdem schon einige Zeilen am Bildschirm angezeigt werden.

UPDATE | INSERT | DELETE ... RETURNING

Für die Kommandos UPDATE, INSERT und DELETE steht die Option RETURNING zur Verfuegung. Damit können diese Operationen für jede aktualisierte, eingefügte oder gelöschte Zeile Werte für output_expression zurückgeben. output_expression ist ein Ausdruck, der aus den aktualisierten Spaltenwerten der Tabelle oder auch Spaltenwerten anderer Tabellen ([ FROM fromlist ] bei einem UPDATE bzw. [ USING usinglist ] bei einem DELETE) zusammengesetzt ist.

Ausserdem kann bei UPDATE und DELETE optional ein Aliasname für die Tabelle angegeben werden. Ist dieser Alias angegeben, wird der originale Tabellenname *verdeckt*.

Erweiterte Syntax für UPDATE, INSERT und SELECT

Die Syntax des UPDATE-Kommandos wurde dahingehend erweitert, dass es jetzt möglich ist, ganze Listen von Werten zu aktualisieren, anstatt für jedes einzelne Feld ein SET-Kommando zu schreiben:

Bei einem INSERT können mehrere Zeilen gleichzeitig in eine Tabelle eingefügt werden:

Bei SELECT-Kommandos können Listen von Feldern und Werten direkt verglichen werden:

Und ausserdem ...

gibt es zahlreiche Performance-Verbesserungen, so dass die Geschwindigkeit von PostgreSQL bei Abfragen bis zu 20% gesteigert werden konnte. Die Einzelheiten können Sie in den PostgreSQL Release Notes 8.2 nachlesen.