Neuheiten 2006
Translated by Karolina Čtrnáctá
Ein Jahr der intensiven Entwicklung von PostgreSQL haben die Forscher mit der Freigabe der Beta Version 8.2 beendet. Auf die Vollversion müssen wir bis Weihnachten warten, doch schon jetzt können wir uns bestimmte Vorstellung von dieser weiteren Version machen. Die Version 8.2. enthält keinen Superreisser wie die beide vorige Versionen. Die meist erwartete Unterstützung der Bitmapindexen und editierenden Blicken fehlt. Aber das bedeutet nicht, dass sich der Übergang auf diese Version nicht auszählt. Diese Version ist wieder merkbar leistungsfähiger als die vorige Version und zusätzlich können wir durch die Modifikation des Parameters FILLFACTOR die Geschwindigkeit der Operationen UPDATE und DELETE beeinflussen. Merkbar (bis um 30 %) ist schneller die Operation COPY.
In der neuen Version können wir auch die Maße der Besetzung (fillfactor) von Datenseiten einstellen. Dieser Wert zeigt um wie viel Prozent werden die Datenseiten für neue Datenspeicher ausgenutzt, und wie viel Raum bleibt an der Datenseite für eventuelle Reihen mit den Befehlen UPDATE und DELETE. Fillfactor muss man als Prozent zwischen 10…100 angeben. Je kleiner er ist, desto größer ist die Wahrscheinlichkeit, dass die aktualisierte Kopie der Zeile an der gleichen Seite wie das Original bleibt, was aus der Sicht des Zugangs mehr effektiv ist, als ihre Stellung an die andere Seite. Dank diesem Umstand müssen wir in einigen Momenten nicht so oft die VACUUM Tabellen starten.
CREATE TABLE FOO(...) WITH (FILLFACTOR = 80);
Die Findung des optimalen Wertes kann allerdings große Alchimie sein. Ich habe probeweise 50% in den intensiv modifizierten Tabellen, welche in pgbench benutzt sind, eingestellt, und damit habe ich wesentlich die Leistung PostgreSQL reduziert. Auf eine Seite wird die Geschwindigkeit der Abfragen an modifizierten Zeilen höher, aber auf der anderen Seite wird höher auch die Nummer der Datenseiten und darauf ist das Sequenzlesen langsamer. Eines der Argumente warum man pg_autovacuum nicht benutzen soll, ist seine Abhängigkeit auf den Betriebsstatistiken. Diese könnten in vorigen Versionen fast 20% Kosten in voll Belastung haben, was schon manchmal Probleme machen konnte. In der Version 8.2 sind die Kosten der Betriebsstatistiken auch unerheblich, aber sie sind halbe (max. 10%). Die Basiskonfiguration von PostgreSQL 8.2 ist um etwas realistischer, hinsichtlich voreingestellteten Parameter der Speicherverwaltung. In vorigen Versionen war eine Regel die Konfigurationsparameter automatisch mehrfach vergrößern. Für die Vollständigkeit zeige ich die Leistung in pgbench der letzten fünf Versionen. Die Konfiguration alter Versionen ist so zubereitet, dass sie der Konfiguration von Version 8.2 anspricht.
| Version | 7.3.15 | 7.4.13 | 8.0.8 | 8.1.4 | 8.2.beta1 |
| tps | 311 | 340 | 334 | 398 | 423 |
Diese Nummern nehmen Sie bitte nur als Anhaltszahlen. Pgbench (TPC-B) ist mehr der Test der Grobstärke, er zeigt zum Beispiel keine sophistische Indexausnützung oder hochentwickelte Optimisierung des Durchführungsplans. Er wurde am durchschnittlichen Notebook P(M)1.6G 512 MB RAM, Fedora6 gemessen. Mehr interessanter würde der Test am Mehrprocessorserver sein, wo sehr evident Abstand zwischen Version 8.x und 7.x ist.
Was gefällt mir am meisten an der Version 8.2? Einen klaren Favorit habe ich nicht. Erfreut etwas intelligentere Aufrufplanung and schnellere Einordnungen. Ich beobachtete auch merkbare Beschleunigung des Sequenzlessen. Vielleicht erleichtert am meistens mein Leben eine Kleinigkeit – die Unterstützung NULL in Feldern (ich bin Programmierer). Jetzt, wenn die Domänen in PL/pgSQL voll unterstützt sind, denke ich über ihrer intensiven Benützung nach. Ich werde mir die Arbeit mit den Rufen ASSERT Prozeduren sparen.
CREATE DOMAIN pos_int int CHECK (VALUE >=0); CREATE OR REPLASE FUNCTION test (p pos_int) REURNS pos_int AS $$ DECLARE v pos_int; BEGIN v := p - 1; RETURN v - 1; END; $$ LANGUAGE plpgsql IMMUTABLE;
Die andere Kleinigkeit, die erfreut, ist die Intervalausrichtung:
justify_interval(Intervall '3 Tage 52 Tage 3 Minuten 2 Sekunden') ->5 Tagen 04:03:02
Regelmässig kommt zur psql Innovation auf. Die Darstellung der wirklich großen Tabelle könnte mit Speicherengpass havarieren. Man kann es mit der Aktivierung des Kursorlesens vorbeugen. Psql zeigt besser Spalte mit der mehrzelligen Text an. Mehrzellige Aufträge sind in der Historie als ein Block gespeichert und darum arbeitet man besser mit der Historie, bzw. erst jetzt ist die Arbeit mit mehrzelligem Auftragen möglich. In den Systemaussichten können wir jetzt die Zeit der letzten vorgenommenen VACUUM und ANALYZE Operationen nachsuchen. Die Liste der Funktionen zeigt den Rückgabentyp und die Parameter inklusive Name und Typ:
postgres=# \df test
Das Blat mit Functionen
Schema | Name | Ergebnis daten Signatur | Argument daten Signatur
--------+------+-------------------+------------------------------------
Publikation| Test | Variable Merkmal | a Ganzzahl, hinaus b Variable Merkmal
(1 row)
Es ist zur Ersetzung des int8 als int4 dort überall gekommen, wo der Umfang nicht mehr genügte (LIMIT, OFFSET). PostgreSQL ermöglicht jetzt eigene mehrparametrische Aggregationsfunktionen. Damit hängt auch die Unterstützung der neuen SQL2003 aggregation binaren Funktionen (corr, regr sxy, …) zusammen. Die Mehrzahl bestehenden Installationsskripten leiden an die Meldung falschen Fehlers, wenn zum Versuch um die Entfernung bis jetzt nicht existierenden Objekten erfolgt. Dieses Problem wird die Erweiterung des Antrags DROP um Phrase IF EXISTS lösen. Der Auftrag TRUNCATE wurde um Antrag CASCADE vergebreitet – effektive Form wie man total die Datei klaren kann. Der Fehler bei ILIKE, der nicht erlaubte es in Mehrbytekodierung benutzen, wurde beseitigt.
Die Windowsbenutzer und vor allem die Gegner des gcc-Translator sicher erfreuet, dass PostgreSQL kann man in Microsoft Visual Studio Übersetzen. Vielleicht Außerhalb der besseren Leistung, ist möglich das Visual Studio zu benutzen. Langsam aber sicher zieht die Portierung an die WIN NT Plattform in Zuverlässigkeit und Leistung sein UNIX Original an. Dieses Ergebnis erfreut die QNX und BEOS Benutzer nicht. Diese Systeme sind schon nicht mehr unterstützt. Die Nativunterstützung des LDAP sollte das Leben den Benutzern, die PostgreSQL an WinNT tummeln, angenehmer machen. Wirksamer Tuning an SUN sollte dank der eingebauten DTrace Unterstützung möglich sein.
Joe Conway und Tom Lane haben den sgn. mehrfachen insert [multi value insert] entwerft. Dank der allgemeinen Lösung ist jetzt auch sgn. table value constructor unterstützt:
postgres=# select a from (Wert(1),(2)) a(a); a --- 1 2 (2 Reihe)
MULTI VALUE INSERT soll nicht den Befehl COPY TO ersetzen. Es ist langsamer und Speicherintensiver. Seine Bedeutung ist in der Reduzierung der Importe aus Dateien, die dump in diesem Format generieren (z.B. MySQL). Nach meiner Kenntnis ist PostgreSQL die einzige Dateibase, die table value constructor nach SQL2003 unterstützt.
Klare Bombe ist doch die Erweiterung der DML Befehlen um Teil RETURNING. Die Syntax ist kompatible mit ORACLE. Worum geht es? Falls wir in diesen Befehlen implizit Werte oder Ausdrucke benutzen, dass wir eigentlich nicht einen genauen Resultat kennen. Sehr oft folgt nach diesem Befehlen der Aufruf, wo wir die gewünschten Werte feststellen (z.B. PK aus den Spalten des Types SERIAL). Die Phrase RETURNING modifiziert die Befehle INSERT, UPDATE und DELETE so, dass sie die Tabelle mit neuen Werten oder beliebigen Ausdrucken zurücksetzt. CREATE TABLE users(id SERIAL PRIMARY KEY, inserted timestamp DEFAULT CURRENT_TIMESTAMP,…):
--8.2. INSERT INTO users (Name, Zurname, ....) VALUES(...) RETURNING *; --8.1 INSERT INTO users (Name, Zurname, ....) VALUES(...); SELECT id, inserted, name, surname WHERE id = lastval();
Für diese Befehle fehlt keine Unterstützung in PL/pgSQL:
CREATE OR REPLACE FUNCTION testa() RETURNS VOID AS $$
DECLARE _a integer; _b integer; _c integer;
BEGIN
FOR _a, _b, _c IN INSERT INTO foo VALUES (10,20,30),(10,11,12) LOOP
RAISE NOTICE '% % %', _a, _b, _c;
END LOOP;
END;
$$ LANGUAGE plpgsql;
Leider kann man nicht SQL Befehl schreiben, wie zum Beispiel:
INSERT INTO archive SELECT * FROM (DELETE FROM dt RETURNING *)
Mit PostgreSQL wurden einige Erweiterungen aus dem Directory contrib oder aus der Repository pgfoundry beendet oder verbessert. Stichweise werde ich einige von ihnen bekannt machen : tsearch2 (fulltext) unterstützt UTF8 und sollte es merklich schneller machen und ermöglicht auch die Benutzung des Wörterbuchs des Open Office, pgstattuple (die Kontrolle des Anteils der toten Sätzen in der Tabelle), pgcrypto (kryptografische Funktion), orafunc (die Implementierung einiger Zehner Funktionen des rdbms Oracle).
Einer massiven Änderung erlebte PL/Python. Die Unterstützung des Pythons ist jetzt auf der gleichen Höhe, oder hoher, wie die Unterstützung des Perl. In Python können wir Funktionen des gemischten Typen verwenden, die Tabellen zurücksetzen, wir können benannte Parameter verwenden. Java ist nicht im Hauptbaum unterstützt, so dass sie mit dem Beta gemeinsam nichts hat, trotzdem ist die Javaunterstützung so ausgereift, dass wir in Java eigene Datentypen entwerfen können. Es ist die einzige Programmierungssprache, außer C, wo es möglich ist. Die SPI Schnittstelle ist mithilfe geordneter JDBC Treiber freigelegt. Alles respektiert ANSI SQL 2003 SQLJ (also theoretisch sollten gespeicherte Prozeduren kompatible mit ORACLE, DB2, usw. sein).
package foo.fee;
import java.util.Iterator;
public class Bar
{
public static Iterator getNames()
{
ArrayList names = new ArrayList();
names.add("Lisa");
names.add("Bob");
names.add("Bill");
names.add("Sally");
return names.iterator();
}
}
CREATE FUNCTION javatest.getNames()
RETURNS SETOF varchar
AS 'foo.fee.Bar.getNames'
IMMUTABLE LANGUAGE java;
Es ist unmöglich die „kommerzielle“ Entwicklung von PostgreSQL nicht zu bemerken. Nach dem erfolglosem Versuch von Great Bridge, versucht nun um dasselbe die EnterpriseDB, die in der Gleichzeitigkeit die Mehrheit der core Entwiklungsspezialisten beschäftigt. Ein paar anderen ist in RedHat, GreenPlum und SkyPe konzentriert. Es bleibt nur ein wenig selbständige Entwickler (z.B. aus Universitäten). Da gibt es nichts zu verwundern. So umfassende und hochwertige Software kann man nicht auf halbe Verpflichtung bilden. Seinen Teil am Erfolg von PostgreSQL bemüht sich auch SUN zu erhalten, der Professional Teams baut und zusammen mit anderen Gesellschaften kommerzielle Unterstützung bietet.
Allerdings schaffte se nicht alle Wünsche der Benutzer zu erfüllen. In Punkten zeige ich die Funktionen auf welche wir bis nächste Version warten müssen: Bitmapindexen, editierte Bilden, rekursive Anfragen, SQL Befehl MERGE, collations Unterstützung, Unterstützung SQL/XML.
Vom weitem habe ich nicht alle Neuigkeiten aufgezählt, die sie jetzt in dem Beta von PostrgreSQL ausprobieren können. Und diejenige, die ich angeführt habe, habe ich nicht so viel Raum geschenkt, wie viel sie sich verdienen. Schon das Beta ist stabil so, wie bei PostgeSQL üblich ist, und ich sehe keinen Grund, warum ich es Ihnen zum Testen nicht empfehlen sollte.