Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us).
Deutsche �bersetzung von Ian Barwick (barwick@gmx.net).
Letzte Aktualisierung der deutschen �bersetzung: Di., den 02.09.2003, 10:00 CET
Die aktuellste Version dieses Dokuments liegt auf der PostgreSQL Website:
�bersetzungen dieses Dokuments in andere Sprachen sowie plattform- spezifische FAQs k�nnen unter http://www.PostgreSQL.org/docs/index.html#faqs eingesehen werden.
Die (englische) Aussprache ist "Post-Gres-Q-L".
PostgreSQL ist eine Weiterentwicklung des POSTGRES-Datenbank-Systems, eines zukunftsweisenden DBMS-Forschungsprototyps. W�hrend PostgreSQL das leistungsf�hige Datenmodell und die reichhaltigen Datentypen von POSTGRES beibeh�lt, ersetzt es dessen PostQuel-Abfragesprache durch eine erweiterte Teilmenge von SQL. PostgreSQL und dessen kompletter Quellcode sind frei und �ffentlich verf�gbar.
Die PostgreSQL-Entwicklung wird von einem Entwickler-Team durchgef�hrt, die alle Teilnehmer der PostgreSQL-Entwicklungs-Mailingliste sind. Der aktuelle Koordinator ist Marc G. Fournier (scrappy@PostgreSQL.org) (Anmeldem�glichkeit: siehe unten). Dieses Team ist f�r die Gesamtentwicklung von PostgreSQL verantwortlich.
Die Autoren von PostgreSQL 1.01 waren Andrew Yu und Jolly Chen. Viele andere haben zur Portierung, zum Testen, zur Fehlersuche und zur Verbesserung des Codes beigetragen. Der urspr�ngliche Postgres-Code, von dem PostgreSQL abstammt, ist auf die Arbeit von vielen Studierenden und Diplomanden sowie Programmierern zur�ckzuf�hren, die unter der Leitung des Professors Michael Stonebraker an der Universit�t von Kalifornien, Berkeley arbeiteten.
Der urspr�ngliche Name der Software in Berkeley war Postgres. Als die SQL-Funktionalit�t 1995 hinzugef�gt wurde, wurde sein Name zu Postgres95 ge�ndert. Der Name wurde Ende 1996 in PostgreSQL ge�ndert.
PostgreSQL unterliegt folgendem COPYRIGHT (Originaltext):
PostgreSQL Data Base Management System
Portions copyright (c) 1996-2002, PostgreSQL Global Development Group Portions Copyright (c) 1994-6 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
Bei der obigen Lizenz handelt es sich um die BSD-Lizenz, die klassiche Open-Source-Lizenz. Sie schr�nkt die Verwendung des Quellcodes in keine Weise ein. Wir m�gen diese Lizenz und haben nicht vor, sie zu �ndern.
Es gilt die Copyright-Klausel im Original!
Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen Plattform eingesetzt werden. Diejenigen Plattformen, die bei der jeweiligen Versionsfreigabe getestet wurden, sind in den Installations- Anleitungen aufgelistet.
Client
Es ist m�glich, die libpq C-Bibliothek, psql sowie andere Client- Anwendungen und Schnittstellen f�r den Einsatz auf MS-Windows-Plattformen zu kompilieren. In diesem Fall l�uft der Client auf MS-Windows und steht �ber TCP/IP mit einem Server in Verbindung, der auf einer der unterst�tzten Unix-Plattformen l�uft. Die Distribution enth�lt die Datei win32.mak, mit der Win32 libpq-Bibliothek und psql erzeugt werden k�nnen.
Server
Der Datenbankserver selber kann mit Hilfe der Cygwin-Umgebung (Unix/NT-Portierungsbibliotheken) auf Windows NT/2000 zum Laufen gebracht werden. Hierzu bitte lesen Sie die in der Distribution enthaltene Datei pgsql/doc/FAQ_MSWIN oder die MS-Windows-FAQ unter http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN.
Eine eigenst�ndige Portierung auf MS Win NT/2000/XP befindet sich in der Vorbereitung.
Weitere Informationen zum Status von PostgreSQL auf der Microsoft-Plattform befinden sich unter http://techdocs.postgresql.org/guides/Windows (en.).
Eine Portierung f�r Novell Netware 6 gibt es unter http://forge.novell.com.
Der zentrale FTP-Server f�r PostgreSQL ist der ftp-Server ftp://ftp.postgreSQL.org/pub. Weitere Mirror-Sites sind auf der PostgreSQL-Website aufgelistet.
Die zentrale (englischsprachige) Mailing-Liste ist: mailto:pgsql-general@PostgreSQL.org .
Die Liste ist Themen vorbehalten, die PostgreSQL betreffen. Die Anmeldung erfolgt mit einer Email an die Adresse pgsql-general-request@PostgreSQL.org mit folgenden Zeilen im Text (nicht in der Betreffzeile):
subscribe
end
Es gibt auch eine Digest-Liste (eine Liste, die Mails zusammengefasst sendet). Um sich an dieser Digest-Liste anzumelden, senden Sie eine Email an pgsql-general-digest-request@PostgreSQL.org mit folgendem Text:
subscribe
end
Es gibt noch die Bug-Mailingliste. Die Anmeldung f�r diese Liste erfolgt durch eine Email an bugs-request@PostgreSQL.org mit folgendem Text:
subscribe
end
Die Entwickler-Mailingliste kann mit einer Email an pgsql-hackers-request@PostgreSQL.org abonniert werden. Die Email mu� ebenfalls folgenden Text enthalten:
subscribe
end
Eine deutschsprachige Mailing-Liste gibt es bei Yahoo Groups: http://de.groups.yahoo.com/group/postgres/; die Liste kann mit einer leeren E-Mail an postgres-subscribe@yahoogroups.de abonniert werden.
Weitere Mailinglisten und Informationen zu PostgreSQL befinden sich auf der PostgreSQL-Homepage:
http://www.PostgreSQL.org
Es gibt au�erdem einen IRC-Channel bei EFNet und bei OpenProjects, Channel #PostgreSQL. Der FAQ-Autor Bruce Momjian nutzt den Unix-Befehl: irc -c '#PostgreSQL' "$USER" irc.phoenix.net um daran teilzunehmen.
Eine Liste von Unternehmen, die Support f�r PostgreSQL auf kommerzieller Basis leisten, kann unter http://techdocs.postgresql.org/companies.php eingesehen werden.
Die neueste Version von PostgreSQL ist 7.3.4 .
Die Freigabe einer neuen Version erfolgt im Schnitt ca. dreimal pro Jahr.
Einige Handb�cher, Man-Pages und einige kleine Testprogramme sind in der Distribution enthalten. Siehe das /doc-Verzeichnis. Ausserdem sind alle Handb�cher online unter http://www.PostgreSQL.org/docs/ verf�gbar.
Zwei B�cher zu PostgreSQL sind online verf�gbar unter http://www.PostgreSQL.org/docs/awbook.html und http://www.commandprompt.com/ppbook/ .
Eine Liste lieferbarer PostgreSQL-B�cher befindet sich unter http://techdocs.PostgreSQL.org/techdocs/bookreviews.php Diverse technische Artikel befinden sich unter http://techdocs.PostgreSQL.org/ .
psql hat einige n�tzliche \d-Befehle, um Informationen �ber Typen, Operatoren, Funktionen, Aggregate, usw. zu zeigen.
PostgreSQL unterst�tzt eine erweiterte Teilmenge von SQL-92. Siehe unsere TODO-Liste unter http://developer.PostgreSQL.org/todo.php f�r eine Auflistung der bekannten Bugs, fehlenden Features und zuk�nftigen Pl�ne.
Das PostgreSQL Book auf http://www.PostgreSQL.org/docs/awbook.html bietet eine Einf�hrung in SQL. Ein weiteres PostgreSQL-Buch befindet sich unter http://www.commandprompt.com/ppbook . Es gibt zudem nette Tutorials unter http://www.intermedia.net/support/sql/sqltut.shtm , http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM und http://sqlcourse.com .
Eine weitere Empfehlung ist "Teach Yourself SQL in 21 Days, Second Edition", es ist unter http://members.tripod.com/er4ebus/sql/index.htm erh�ltlich.
Viele PostgreSQL-Anwender m�gen "The Practical SQL Handbook" (Bowman et al., Addison Wesley). Andere dagegen m�gen "The Complete Reference SQL" (Groff et al., McGraw-Hill).
Ja, wir k�nnen Datumsangaben nach dem Jahr 2000 n.Chr. und vor 2000 v.Chr. leicht verarbeiten.
Zuerst laden Sie die neuesten Quellen herunter und lesen Sie die PostgreSQL-Entwicklerunterlagen auf unserer Website oder in der Distribution. Dann melden Sie sich zu den Entwickler-Mailinglisten pgsql-hackers und pgsql-patches an. Anschlie�end senden Sie qualitativ hochwertige Patches an die pgsql-patches Mailingliste.
Es gibt ungef�hr ein Dutzend Leute, die das commit-Recht im PostgreSQL CVS-Archiv haben. Alle haben derart viele hochwertige Patches eingebracht, dass es f�r die CVS-Verwalter schwer war, mitzuhalten. Und wir hatten Vertrauen, dass die von ihnen festgelegten �nderungen aller Wahrscheinlichkeit nach von hoher Qualit�t sind.
Bitte besuchen Sie die PostgreSQL-BugTool-Seite http://www.PostgreSQL.org/bugs/, die Hinweise und Anleitungen zur Einreichung von Fehlerberichten enth�lt.
�berpr�fe auch den ftp-Server ftp://ftp.PostgreSQL.org/pub, um nachzusehen, ob es eine neuere PostgreSQL-Version oder neue Patches gibt.
Es gibt verschiedene Methoden, Software zu messen: Eigenschaften, Leistung, Zuverl�ssigkeit, Support und Preis.
PostgreSQL besitt die meisten Eigenschaften - wie Transaktionen, Unterabfragen (Subqueries), Trigger, Views und verfeinertes Locking - die bei gro�en kommerziellen DBMS vorhanden sind. Es bietet au�erdem einige anderen Eigenschaften, die diese nicht haben, wie benutzerbestimmte Typen, Vererbung, Regeln, und die Multi-Versionen-Steuerung zum Verringern konkurrierender Locks.
PostgreSQL weist eine Performanz auf, die mit der von kommerziellen und anderen Open-Source-Datenbanken vergleichbar ist. In manchen Bereichen ist es schneller, in anderen langsamen. Im Vergleich zu MySQL oder abgespeckten Datenbank-Systemen sind INSERT- und UPDATE-Anweisungen aufgrund des Transaktionsaufwands langsamer. MySQL hat allerdings keine der oben erw�hnten Eigenschaften. PostgreSQL setzt auf Zuverl�ssigkeit und Funktionsumfang, obwohl selbstredend st�ndig an Performanz- Verbesserungen gearbeitet wird. Ein interessanter Vergleich zwischen PostgreSQL und MySQL befindet sich unter dieser URL: http://openacs.org/philosophy/why-not-mysql.html
Wir stellen fest, dass ein DBMS wertlos ist, wenn es nicht zuverl�ssig arbeitet. Wir bem�hen uns, nur streng gepr�ften, best�ndigen Code freizugeben, der nur ein Minimum an Programmfehler aufweist. Jede Freigabe hat mindestens einen Monat Betatest-Phase hinter sich, und unsere Freigabehistorie beweist, dass wir stabile, solide Versionen freigeben, die im Produktionsbetrieb genutzt werden k�nnen. Wir glauben, dass wir im Vergleich mit anderer Datenbanksoftware vorteilhaft dastehen.
Unsere Mailinglisten bieten die M�glichkeit, gemeinsam mit einer gro�en Gruppe von Entwicklern und Benutzern m�gliche Probleme zu l�sen. Wir k�nnen nicht immer eine Fehlerbehebung garantieren, kommerzielle DBMS tun dies aber auch nicht. Der direkte Kontakt zur Entwickler- und Benutzergemeinschaft, der Zugriff auf die Handb�cher und auf den Quellcode erm�glicht einen im Vergleich zu anderen DBMS h�herwertigen Support. Es gibt jedoch auch Anbieter von kommerziellen Support-Leistungen (siehe FAQ-Punkt 1.6).
PostgreSQL ist frei verf�gbar, sowohl f�r die kommerzielle wie f�r die nicht-kommerzielle Nutzung. Sie k�nnen den PostgreSQL-Code ohne Einschr�nkungen (au�er denjenigen, die in der oben angegebene BSD-artigen Lizenz erw�hnt werden) in Ihr Produkt integrieren.
PostgreSQL hat seit dem Anfang in 1996 eine exzellente Infrastruktur. Dies ist Marc Fournier zu verdanken, der sie �ber die Jahre hinweg geschaffen und gepflegt hat.
Eine hochwertige Infrastruktur ist f�r ein Open-Source-Projekt wie dieses sehr wichtig. Sie verhindert Probleme und Verz�gerungen beim Fortschritt des Projekts.
Selbstverst�ndlich ist diese Infrastruktur nicht billig. Es gibt eine Reihe von einmaligen und monatlich wiederkehrenden Kosten, die f�r den Weiterbetrieb beglichen werden m�ssen. Falls Sie oder Ihre Firma dazu finanziell beitragen k�nnen, besuchen Sie bitte die URL http://store.pgsql.com/shopping/ wo Sie eine Spende abgeben k�nnen.
Obwohl diese Web-Seite das Unternehmen "PostgreSQL, Inc." erw�hnt, ist der Bereich "contributions" (Beitr�ge) ausschliesslich f�r die Unterst�tzung des PostgreSQL-Projekts da und nicht f�r die Finanzierung einer bestimmten Firma. Sie k�nnen auch gerne einen finanziellen Beitrag an die Kontaktadresse verschicken.
Eine M�glichkeit der nicht-finanziellen Untetst�tzung besteht �brigens darin, f�r http://advocacy.postgresql.org (en.) bzw. http://advocacy.postgresql.org/?lang=de (dt.) einen Bericht �ber den erfolgreichen Einsatz von PostgreSQL in Ihrem Unternehmen oder Organisation bereitzustellen.
Es sind zwei ODBC-Treiber verf�gbar: PsqlODBC und OpenLink ODBC.
PsqlODBC kann von http://gborg.postgresql.org/project/psqlodbc/projdisplay.php heruntergeladen werden.
OpenLink ODBC kann unter http://www.openlinksw.com geholt werden. Die Software arbeitet mit dem Standard-ODBC-Client dieser Firma, so dass PostgreSQL-ODBC auf jeder Client-Plattform zur Verf�gung steht, die unterst�tzt wird (Win, Mac, Unix, VMS).
OpenLink wird dieses Produkt wahrscheinlich an Leute verkaufen, die kommerziellen Support ben�tigen, dennoch wird immer eine Freeware-Version verf�gbar sein. Fragen dazu bitte an postgres95@openlink.co.uk.
Eine nette Einf�hrung zu datenbank-gest�tzten Webseiten kann unter http://www.webreview.com (engl.) abgerufen werden.
F�r die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP gibt es bei http://www.php.net
F�r komplexere Aufgaben bietet sich die Perl-Schnittstelle mit CGI.pm oder mod_perl.
Es gibt mehrere grafische Schnittstellen f�r PostgreSQL, darunter PgAccess ( http://www.pgaccess.org), PgAdmin II (http://www.pgadmin.org, nur f�r Win32), RHDB Admin (http://sources.redhat.com/rhdb/ ) und Rekall ( http://www.thekompany.com/products/rekall/, propriet�r). Es gibt au�erdem PHPPgAdmin ( http://phppgadmin.sourceforge.net/ ), eine web-basierte Schnittstelle.
Die meisten g�ngigen Programmiersprachen bieten Schnittstellen f�r PostgreSQL.
Die folgenden Schnittstellen werden mit der PostgreSQL-Distribution ausgeliefert:
Weitere Schnittstellen f�r andere Sprachen k�nnen �ber http://gborg.postgresql.org (Bereich Drivers/Interfaces) bezogen werden.
Bei der Ausf�hrung von configure die Option --prefix mit dem Zielverzeichnis angeben.
Das kann verschiedene Ursachen haben. �berpr�fen Sie zuerst, ob Ihr Kernel System V Extensions unterst�tzt. PostgreSQL ben�tigt Kernel-Unterst�tzung f�r Shared Memory und Semaphoren.
Entweder ist Shared Memory in Ihrem Kernel nicht korrekt konfiguriert, oder Sie m�ssen den Shared Memory Bereich vergr��ern. Die genaue Gr��e h�ngt von Ihrer Systemarchitektur und von der Anzahl der Puffer und Serverprozesse ab, die Sie f�r postmaster konfiguriert haben. Bei den voreingestellten Werten f�r Puffer und Prozesse ben�tigen Sie bei den meisten Systemen ein Minimum von ca. 1 MB. Der "PostgreSQL Administrator's Guide" (http://www.PostgreSQL.org/docs/view.php?version=current&idoc=1&file=kernel-resources.html) enth�lt weitere Informationen zu Shared Memory und Semaphores.
Falls die Fehlermeldung "IpcSemaphoreCreate: semget failed (No space left on device)" lautet, ist Ihr Kernel mit zu wenig Semaphoren konfiguriert. PostgreSQL ben�tigt eine Semaphore pro m�glichem Backend-Prozess. Eine Zwischenl�sung w�re, postmaster mit einer geringeren Anzahl an Backend-Prozessen zu starten. Benutzen Sie dazu die -N Option mit einem kleineren Wert als die standardm��igen 32. Eine dauerhafte L�sung w�re es, die Parameter SEMMNS und SEMMNI Ihres Kernels zu erh�hen.
Nichtfunktionierende Semaphores k�nnen au�erdem bei hoher Datenbanklast zu Abst�rzen f�hren.
Falls die Fehlermeldung anders aussieht, ist m�glicherweise keine Semaphoren-Unterst�tzung in Ihrem Kernel aktiviert. Der "PostgreSQL Administrator's Guide" enth�lt weitere Informationen zu Shared Memory und Semaphores.
PostgreSQL ist standardm��ig so eingestellt, dass Verbindungen nur vom lokalen Rechner �ber Unix Domain Sockets m�glich sind. Verbindungen von anderen Rechnern �ber TCP/IP sind nur m�glich, wenn der postmaster mit der -i Option gestartet wird und die host-basierte Authentifizierung in der Datei $PGDATA/pg_hba.conf entsprechend angepasst ist.
Der Einsatz von Indizes sollte auf jeden Fall Abfragen beschleunigen. Die Anweisung EXPLAIN zeigt, wie PostgreSQL Abfragen interpretiert und welche Indizes benutzt werden.
Wenn Sie eine gro�e Anzahl von INSERT-Anweisungen durchf�hren, sollten Sie �berlegen, ob die Durchf�hrung mit der COPY-Anweisung in Frage kommt. Dies funktioniert wesentlich schneller als einzelne INSERT-Befehle. SQL-Anweisungen, die sich nicht in einem BEGIN WORK/COMMIT Transaktions- Block befinden, werden als eigene Transaktionen behandelt. �berlegen Sie, ob die Anweisungen nicht in einen einzelnen Transaktionsblock zusammen- gefasst werden k�nnen. Das reduziert den Transaktionsaufwand. �berlegen Sie auch, bei gr��eren Daten�nderungen Indizes zu l�schen und danach wiederherzustellen.
Es gibt verschiedene Tuning-Optionen. Sie k�nnen fsync() ausschalten, indem Sie beim Starten des postmaster die Optionen -o -F angeben. Das hindert fsync()-Operationen daran, nach jeder Transaktion die Daten direkt auf die Festplatte zu schreiben.
Sie k�nnen auch mit der -B Option des postmaster die Anzahl der Shared Memory Puffer f�r die Backend-Prozesse erh�hen. Falls Sie diesen Wert jedoch zu hoch setzen, kann es vorkommen, dass der postmaster nicht startet, weil die Obergrenze der Speicherzuweisung f�r Shared Memory �berschritten wird. Jeder Puffer ist 8 kB gro�, standardm��ig gibt es 64 Puffer.
Sie k�nnen auch die -S Option des Backends nutzen, um die Gr��e des Speicherplatzes f�r tempor�res Sortieren zu erh�hen. Der -S Wert wird in Kilobyte gemessen und ist standardm��ig auf 512 kB festgelegt.
Die CLUSTER-Anweisung kann benutzt werden, um Daten in Basistabellen zu gruppieren, so dass sie auf einen Index zusammengebracht werden. Siehe auch die CLUSTER(l) Man-Page f�r weitere Details.
PostgreSQL hat einige M�glichkeiten, Statusinformationen anzuzeigen, die bei der Fehlersuche n�tzlich sein k�nnen.
Wenn Sie PostgreSQL mit dem --enable-cassert Option kompiliert haben, verfolgen zahlreiche assert()-Anweisungen den Ablauf des Backends und halten das Programm an, wenn etwas Unerwartetes passiert.
Sowohl der postmaster als auch postgres stellen mehrere Debug-Optionen zur Verf�gung. Stellen Sie zuerst sicher, dass Sie den Standard-Output und den Fehlerkanal in eine Datei umleiten, wenn Sie den postmaster starten:
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
Dadurch wird die Datei server.log im PostgreSQL-Verzeichnis erzeugt. Diese Datei enth�lt n�tzliche Informationen �ber Probleme oder Fehler, die im Server aufgetreten sind. postmaster hat eine -d Option, die noch detailliertere Informationen liefert. Zur -d Option wird eine Nummer angegeben, die den Debug-Level - also die Menge der berichteten Information - angibt. Achtung, hohe Debug-Levels erzeugen schnell gro�e Logdateien!
Wenn der postmaster nicht l�uft, k�nnen Sie sogar den postgres-Backend von der Befehlszeile ausf�hren und eine SQL-Anweisung direkt eingeben. Dies ist nur f�r Debugging-Zwecke zu empfehlen. Beachten Sie, dass ein Zeilenumbruch, und nicht das Semikolon die SQL-Anweisung beendet. Falls Sie PostgreSQL mit Debugging-Symbolen kompiliert haben, k�nnen Sie mit einem Debugger sehen, was passiert. Da das Backend jedoch nicht vom postmaster gestartet wurde, l�uft es nicht in der gleichen Umgebung und deshalb k�nnen einige locking/backend Operationen nicht reproduziert werden.
Wenn dagegen der postmaster l�uft, f�hren Sie psql in einem Fenster aus, dann ermitteln Sie die Prozessnummer (PID) des postgres-Prozesses, der von psql verwendet wird. Binden Sie einen Debugger an diese PID und f�hren Sie Abfragen von psql aus. Wenn Sie den postgres-Serverstart analysieren wollen, setzen Sie die Umgebungsvariable PGOPTIONS="-W n", und starten Sie dann psql. Dies verz�gert den Start um n Sekunden, damit Sie einen Debugger an den Prozess binden k�nnen und ggf. Breakpoints setzen, bevor die Startsequenz begonnen wird.
Das Programm postgres hat auch die Optionen -s, -A und -t, die bei der Fehlersuche und Performanzmessung sehr n�tzlich sein k�nnen.
Sie k�nnen die Anwendung auch mit Profiling kompilieren, um zu sehen, welche Funktionen wieviel Ausf�hrungszeit beanspruchen. Das Backend Profil wird im Verzeichnis pgsql/data/base/dbname abgelegt. Das Client-Profil wird in das aktuelle Verzeichnis abgelegt. Bitte beachtern Sie, dass unter Linux PostgreSQL mit der Option -DLINUX_PROFILE kompiliert werden mu�, um Profiling nutzen zu k�nnen.
Sie m�ssen die maximale Anzahl der gleichzeitig ausf�hbaren Backend- Prozesse hochsetzen.
Die Voreinstellung ist 32 Prozesse. Sie k�nnen diese erh�hen, indem Sie den postmaster mit einem entsprechenden -N Parameter starten bzw. die Konfigurationsdatei postgresql.conf anpassen.
Bitte beachten Sie, dass Sie auch -B auf ein Wert gr��er als die Voreinstellung von 64 setzen m�ssen, wenn Sie -N auf einen Wert h�her als 32 setzen; -B muss mindestens das Doppelte von -N betragen, und einer besseren Performanz wegen sollte der Wert noch h�her sein. Bei einer hohen Anzahl von Backend-Prozessen kann es vorkommen, dass Sie einige Unix-Kernel- Parameter ebenfalls erh�hen m�ssen. Folgende Parameter sind zu �berpr�fen: die Maximalgr��e der Shared Memory Blocks SHMMAX; die Maximalanzahl der Semaphoren SEMMNS und SEMMNI; die maximale Anzahl von Prozessen NPROC; die maximale Anzahl von Prozessen pro User MAXUPRC; und die Maximalzahl der ge�ffneten Dateien NFILE und NINODE. Durch die Begrenzung der Anzahl erlaubter Backend-Prozesse wird verhindert, dass System-Ressourcen durch PostgreSQL aufgebraucht werden.
Dieses Verzeichnis enth�lt tempor�re Dateien, die durch den query executor erzeugt werden. Wenn zum Beispiel eine Sortierung durchgef�hrt werden mu�, um ein ORDER BY auszuf�hren, und diese Sortierung mehr Hauptspeicher ben�tigt, als mit dem Backend-Parameter -S erlaubt wurde, dann werden diese Dateien erzeugt, um die Daten dort zu auszulagern.
Die tempor�ren Dateien sollten automatisch gel�scht werden. Falls das Backend jedoch w�hrend einer Sortierung abst�rzen sollte, bleiben sie erhalten. Nach einem Neustart des postmaster werden sie auomatisch gel�scht.
Zwischen "kleinen" PostgreSQL-Versions�nderungen (z.B. zwischen 7.2 und 7.2.1) werden keine strukturellen �nderungen durchgef�hrt, wodurch ein erneutes Aus- und Einlesen der Daten nicht ben�tigt wird. Allerdings wird bei "gro�en" Versions�nderungen (z.B. zwischen 7.2 und 7.3) oft das interne Format der Systemtabellen und Datendateien angepasst. Diese �nderungen sind oft sehr komplex, wodurch die R�ckw�rtskompatibilit�t der Datendateien nicht gew�hrleistet werden kann. Durch das Exportieren werden die Daten in einem generischen Format ausgegeben, wodurch die Importierung in das neue interne Format erm�glicht wird.
Bei Versionenwechseln, wo kein Format�nderungen stattgefunden haben, kann das pg_upgrade-Skript benutzt werden, um die Daten ohne Aus- und Einlesen zu �bertragen. Die jeweilige Dokumentation gibt an, ob f�r die betreffende Version pg_upgrade verf�gbar ist.
Vgl. die DECLARE Man-Page f�r eine Beschreibung.
Vgl. die FETCH Man-Page, oder benutzen Sie SELECT ... LIMIT... .
Selbst wenn Sie nur die ersten paar Zeilen einer Tabelle abfragen m�chten, mu� unter Umst�nden die komplette Abfrage abgearbeitet werden. Ziehen Sie also m�glichst eine Abfrage in Erw�gung, die eine ORDER BY-Anweisung benutzt, die wiederum auf indizierte Spalten verweist. In diesem Fall kann PostgreSQL direkt nach den gew�nschten Zeilen suchen und braucht nicht jede m�gliche Ergebniszeile abzuarbeiten.
Bitte beachten Sie, dass mit PostgreSQL 7.3 die Syntax LIMIT n, m durch LIMIT n OFFSET m ersetzt wurde.
Um eine beliebige Zeile auszuw�hlen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1;
Sie k�nnen sich die Datei pgsql/src/bin/psql/describe.c mit dem Quellcode f�r psql ansehen. Sie enth�lt die SQL-Abfragen, die die Backslash-Kommandos (\) ausf�hren. Sie k�nnen psql auch mit der -E Option starten. Danach gibt psql die Abfragen aus, die es bei der Ausf�hrung der Befehle benutzt.
Der Syntax ALTER TABLE DROP COLUMN wird ab PostgreSQL 7.3 unterst�tzt.
Bei fr�heren Versionen bietet das folgende Verfahren Ersatz:
BEGIN;
LOCK TABLE old_table;
SELECT ... -- alle au�er der zu entfernenden Spalte hier ausw�hlen
INTO TABLE new_table
FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
COMMIT;
Um den Datentyp einer Spalte zu �ndern, gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;
Um den Platz zu reklamieren, der von der gel�schten Spalte verwendet wurde, f�hren Sie VACUUM FULL aus.
Es bestehen folgende Obergrenzen:
Maximale Gr��e eine Datenbank? unbeschr�nkt (es existieren
Datenbanken mit 4TB)
Maximale Gr��e einer Tabelle? 16 TB
Maximale Gr��e einer Zeile? 1,6 TB
Maximale Gr��e einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschr�nkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indizies f�r eine Tabelle?
unbeschr�nkt
Selbstverst�ndlich sind dies theoretische Werte, die oft durch die verf�gbaren Platten- und Speicherressourcen eingeschr�nkt sind. Extreme Gr��en k�nnen zu Leistungseinbu�en f�hren.
Die maximale Tabellengr��e von 16 TB ben�tigt keine Large-File-Unterst�tzung im Betriebssystem. Gro�e Tabellen werden in Dateien mit einer Gr��e von 1 GB aufgeteilt, wodurch etwaige dateisystem-bedingte Beschr�nkungen nicht relevant sind.
Die maximale Tabellengr��e und die maximale Anzahl von Spalten k�nnen gesteigert werden, wenn die Default-Blockgr��e auf 32 KB heraufgesetzt wird.
Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen Textdatei bis zu f�nfmal mehr Platz gegen�ber der eigentlichen Gr��e der Datei beanspruchen.
Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die durchschnittliche L�nge der Textbeschreibung 20 Byte betr�gt. Die einfache Datei w�rde 2,8 MB gro� sein. Die Gr��e der PostgreSQL-Datenbankdatei, die diese Daten enth�lt, liegt ungef�hr bei 6,4 MB:
36 Bytes: jeder Zeilenkopf (ungef�hr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
64 Bytes pro Zeile
Die Gr��e einer Datenseite in PostgreSQL betr�gt 8192 Bytes (8 KB), also:
8192 Bytes pro Seite
--------------------- = 128 Zeilen pro Seite (abgerundet)
64 Bytes pro Zeile
100.000 Datenzeilen
----------------------- = 782 Datenbankseiten (aufgerundet)
128 Zeilen pro Seite
782 Datenbankseiten * 8192 Bytes pro Seite = 6.406.144 Byte (6,4 MB)
Indizes beanspruchen nicht so viel Platz. Da sie jedoch die Daten beinhalten, die sie indizieren, k�nnen auch sie sehr gro� werden.
NULL-Werte werden in Bitmaps gespeichert, wodurch sie sehr wenig Platz in Anspruch nehmen.
psql hat eine Vielzahl von Backslash-Befehlen, mit denen solche Informationen angezeigt werden k�nnen. Der Befehl \? zeigt eine �bersicht. Au�erdem zeigt der Befehl \l eine Liste von allen verf�gbaren Datenbanken an.
Die Datei pgsql/src/tutorial/syscat.source enth�lt au�erdem viele SELECT-Anweisungen, mit deren Hilfe man Information �ber die Systemtabellen erhalten kann.
Indizes werden nicht automatisch bei jeder Abfrage verwendet. Indizes werden nur dann verwendet, wenn die abzufragende Tabelle eine bestimmte Gr��e �bersteigt, und die Abfrage nur eine kleine Prozentzahl der Tabellenzeilen abfragt. Grund hierf�r ist, dass die durch einen Index verursachten Festplattenzugriffe manchmal langsamer sind als ein einfaches Auslesen aller Tabellenzeilen (sequentieller Scan).
Um festzustellen, ob ein Index verwendet werden soll, braucht PostgreSQL Statistiken �ber die Tabelle. Diese Statistiken werden durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand der Statistiken kennt der Abfragenoptimierer die Anzahl der Tabellenzeilen und kann besser entscheiden, ob Indizes verwendet werden sollen. Statistiken sind auch bei der Feststellung optimaler JOIN-Reihenfolge und -Methoden wertvoll.
Indizes werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs verwendet. Ein sequentieller Scan mit anschlie�endem explizitem Sortiervorgang ist normalerweise schneller als ein Index-Scan einer gro�en Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein kleiner Abschnitt der Tabelle zur�ckgeliefert wird. Dadurch wird es auch m�glich, die Minimal- und Maximalwerte einer Abfrage unter Verwendung von Indizes zu ermitteln:
SELECT spalte
FROM tabelle
ORDER BY spalte [ DESC ]
LIMIT 1
(Die Aggregatfunktionen MIN() und MAX() verwenden keine Indizes).
Sollte es danach aussehen, also ob der Optimierer irrt�mlich einen sequentiellen Scan ausf�hrt, f�hren Sie SET enable_seqscan TO 'off' aus und pr�fen Sie, ob die Indexabfrage dadurch scheller geworden ist.
Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, k�nnen Indizes nur unter bestimmten Umst�nden verwendet werden:
Suchmuster, die Gross- und Kleinschreibung nicht ber�cksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indizes. Stattdessen k�nnen funktionale Indizes verwendet werden, die im Punkt 4.12 beschrieben werden.
Die C-Locale mu� w�hrend der Datenbank-Initialisierung mit initdb bestimmt worden sein.
Vgl. die EXPLAIN Man-Page.
Ein R-Tree Index wird benutzt, um r�umliche Daten zu indizieren. Ein Hash-Index kann nicht f�r Bereichssuchen genutzt werden. Ein B-Tree Index kann nur f�r Bereichssuchen in eindimensionalen Daten genutzt werden. R-Trees k�nnen multi-dimensionale Daten abhandeln. Ein Beispiel: Wenn ein R-Tree Index auf ein Attribut vom Typ POINT gebildet wird, dann kann das System Abfragen wie z.B. "Zeige alle Punkte, die sich in einem umgebenden Rechteck befinden" effizienter beantworten.
Die kanonische Ver�ffentlichung, die das originale R-Tree Design beschreibt, ist:
Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
Sie k�nnen dieses Werk auch in Stonebrakers "Readings in Database Systems" finden.
Die eingebauten R-Trees k�nnen Polygone und Rechtecke verarbeiten. Theoretisch k�nnen R-Trees auf eine hohe Anzahl von Dimensionen erweitert werden. Praktisch bedingt diese Erweiterung eine Menge Arbeit und wir haben derzeit keinerlei Dokumentation dar�ber, wie das zu machen w�re.
Das GEQO-Modul in PostgreSQL soll dazu dienen, das Optimierungsproblem beim JOIN von vielen Tabellen auf der Basis genetischer Algorithmen (GA) zu l�sen. Es erm�glicht die Behandlung von gro�en JOIN-Queries durch eine nicht-ersch�pfende Suche.
Der Operator ~ bewirkt die Anwendung eines regul�ren Ausdrucks. ~* f�hrt zur Anwendung eines regul�ren Ausdrucks mit Ignorierung der Gro�- und Kleinschreibung.
Gleichheitsvergleiche, die Gro�- und Kleinschreibung ignorieren, werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'
Ein funktionaler Index, der wie folgt erstellt wird, wird auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))
Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
Typ interner Name Bemerkungen
-------------------------------------------------
VARCHAR(n) varchar die Gr��e legt die Maximall�nge fest; kein
Ausf�llen mit Leerzeichen
CHAR(n) bpchar mit Leerzeichen gef�llt bis zur angegebenen L�nge
TEXT text Die L�nge wird nur durch die maximale Zeilenl�nge
beschr�nkt
BYTEA bytea Bytearray mit variabler L�nge
"char" char 1 Zeichen
Der interne Name kommt vor allem in den Systemkatalogen und in manchen Fehlermeldungen vor.
Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes geben die L�nge an, gefolgt von den Daten). Daher ist der tats�chlich belegte Platz immer etwas mehr als die deklarierte Feldgr��e. Allerdings wird unter Umst�nden auf diese Datentypen Datenkompression durch das TOAST- Verfahren angewendet, womit der tats�chlich belegte Platz auch geringer als erwartet ausfallen kann.
F�r die Speicherung von Zeichenketten variabler L�nge empfiehlt sich VARCHAR(n). Die maximale L�nge eines VARCHAR(n)-Felds wird bei der Tabellendefinition festgelegt. TEXT setzt keine L�ngengrenze, allerdings gibt es eine systembedingte Obergrenze von 1 GB.
CHAR(n) ist geeignet f�r die Speicherung von Zeichenketten, die alle die gleiche L�nge haben. Bitte beachten Sie, dass CHAR(n) automatisch Zeichenketten bis zur definierten Feldl�nge mit Leerzeichen ausf�llt, w�hrend bei VARCHAR(n) nur die tats�chlich eingegebene Zeichenkette gespeichert wird.
BYTEA ist f�r bin�re Daten, besonders f�r Werte, die NULL-Bytes haben.
Die hier erw�hnten Typen weisen �hnliche Performanzeigenschaften auf.
PostgreSQL bietet einen SERIAL-Datentyp. Dieser erzeugt automatisch eine Sequenz und einen Index auf die angegebene Spalte. Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)
wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
CREATE UNIQUE INDEX person_id_key ON person ( id );
umgewandelt.
Die create_sequence Man-Page liefert weitere Informationen �ber Sequenzen. Es ist auch m�glich, den OID-Wert jeder Spalte als einmaligen Wert einzusetzen. Sollten Sie allerdings die Datenbank exportieren und reimportieren wollen, m�ssen Sie die Option -o von pg_dump bzw. COPY WITH OIDS verwenden, um die OIDs beizubehalten.
Eine M�glichkeit w�re, mit der nextval()-Funktion den n�chsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuf�hrung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.15.1 k�nnte dieser Vorgang in einer Pseudosprache so aussehen:
new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
Danach st�nde der neue Wert in der Variablen new_id f�r die Verwendung in weiteren Abfragen zur Verf�gung, zum Beispiel als Fremdschl�ssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: <table>_<serialcolumn>_seq wobei 'table' und 'serialcolumn' die Namen der jeweils betreffenden Tabelle / Spalte darstellen.
Als weitere M�glichkeit k�nnen Sie nach einer INSERT-Anweisung den automatisch eingef�gten SERIAL-Wert mit der currval()-Funktion zur�ckgeben lassen:
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");
Schlie�lich besteht noch die M�glichkeit, den von einer INSERT-Anweisung zur�ckgelieferten OID-Wert als einmaligen Wert zu verwenden. Dieser Ansatz ist allerdings PostgreSQL-spezifisch; au�erdem wird nach ca. 4 Milliarden Eintr�gen der OID-Wert wieder auf eine kleine Zahl gesetzt, ist also nicht garantiert einmalig.
In Perl mit dem DBD::Pg-Modul wird der OID-Wert nach einem $sth->excute() �ber $sth->{pg_oid_status} zur�ckgeliefert.
Nein. Die Funktionen liefern einen Wert zur�ck, der von Ihrem Backend bestimmt wird, und der anderen Benutzern nicht zur Verf�gung steht.
Um die konkurrente Verarbeitung zu verbessern, werden Sequenzwerte nach Bedarf an laufende Transaktionen zugeteilt und erst beim Abschlu� der Transaktion gesperrt. Durch abgebrochene Transaktionen werden L�cken in der Sequenznummerierung verursacht.
OIDs sind PostgreSQLs Antwort auf eindeutige Zeilen-IDs. Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID. Alle OIDs, die durch initdb erzeugt werden, sind kleiner als 16384 (siehe include/access/transam.h). Alle OIDs, die durch den Benutzer erzeugt werden, sind gleich oder gr��er als dieser Wert. Standardm��ig sind all OIDs nicht nur innerhalb einer Tabelle oder Datenbank, sondern in der gesamten PostgreSQL-Installation einmalig.
PostgreSQL benutzt OIDs in seinen internen Systemtabellen, um Zeilen in JOINs zwischen Tabellen zu verkn�pfen. Es ist m�glich, einen Index f�r die OID-Spalte zu erstellen, wodurch schnellere Zugriffszeiten erreicht werden k�nnen. Es wird empfohlen, OID-Werte in Spalten vom Typ OID zu speichern.
OIDs werden allen neuen Zeilen von einem zentralen Bereich, der von allen Datenbanken genutzt wird, zugewiesen. Nichts hindert Sie daran, die OID zu �ndern, oder eine Kopie der Tabelle mit den originalen Oids anzulegen:
CREATE TABLE new_table(old_oid OID, mycol INT);
SELECT INTO new SELECT old_oid, mycol FROM old;
COPY new TO '/tmp/pgtable';
DELETE FROM new;
COPY new WITH OIDS FROM '/tmp/pgtable';
Einige der Quelltexte und die �ltere Dokumentation nutzen allgemeine Begriffe. Hier sind einige aufgef�hrt:
Eine allgemeine Liste der Datenbank-Terminologie erhalten Sie hier: http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html (engl.).
Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System oder Ihr Kernel hat niedrige H�chstgrenzen f�r bestimmte Ressourcen. Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m
Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich ausgef�hrt werden. Auf jedem Fall wird die Grenze des Datensegments f�r Prozesse erh�ht werden und eventuell die erfolgreiche Ausf�hrung der Abfrage erm�glichen. Falls Sie ein Problem mit dem SQL-CLient haben, weil das Backend zu viele Daten zur�ckliefert, versuchen Sie dies vor dem Start des SQL-Clients.
Sie sollten die Anweisungen BEGIN WORK und COMMIT bei jeden Gebrauch von Large Objects benutzen. Also um lo_open ... lo_close.
Derzeit erzwingt PostgreSQL diese Regel, indem es die Handles der Large Objects beim COMMIT der Transaktion schlie�t. So f�hrt der erste Versuch, etwas mit dem Large Object zu machen, zu einer Meldung "invalid large obj descriptor". Solange Sie keine Transaktionen benutzen, wird der Code, der in �lteren PostgreSQL-Versionen funktionierte, nun diese Fehlermeldung erzeugen.
Falls Sie eine Client-Schnittstelle wie ODBC benutzen, kann es sein, dass die auto-commit-Option ausgeschaltet werden muss.
Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
Derzeit werden Unterabfragen mit der �usseren Abfrage verbunden, indem f�r jede Reihe der �usseren Query die Ergebnisse der Unterabfrage sequentiell gepr�ft werden. Um dies zu vermeiden, kann man IN durch EXISTS ersetzen, z.B.:
SELECT *
FROM tabelle_1
WHERE spalte1 IN (SELECT spalte2 FROM tabelle_2)
in:
SELECT *
FROM tabelle_1
WHERE EXISTS (SELECT spalte2 FROM tabelle_2 WHERE spalte1 = spalte2)
Damit diese Abfrage effizient durchgef�hrt wird, sollte f�r 'spalte2' ein Index angelegt worden sein. Die Einschr�nkung von Abfragen mit IN wird in der n�chsten PostgreSQL-Version (7.4) behoben werden.
PostgreSQL ab der Version 7.1 unterst�tzt OUTER JOINs nach dem SQL- Standardsyntax. Hier zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)
bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)
Diese identischen Abfragen verkn�pfen tabelle_1 mit tabelle_2 �ber die Spalte 'spalte' und geben au�erdem alle unverkn�pften Zeilen in tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben) zur�ck. Ein FULL JOIN w�rde dagegen alle verkn�pften Zeilen sowie jeweils alle unverkn�pften Zeilen aus den beiden Tabellen verkn�pfen. Die Angabe von OUTER ist nicht zwingend und kann in LEFT, RIGHT und FULL-Verkn�pfungen weggelassen werden. Normale Verkn�pfungen sind INNER JOINs.
In fr�heren Versionen von PostgreSQL k�nnen OUTER JOINs mittels UNION und NOT IN simuliert werden. Zum Beispiel 'tabelle_1' und 'tabelle_2' k�nnen als LEFT OUTER JOIN auch so verkn�pft werden:
SELECT t1.spalte1, t2.spalte2
FROM tabelle_1 t1, tabelle_2 t2
WHERE t1.spalte1 = t2.spalte1
UNION ALL
SELECT t1.spalte1, NULL
FROM tabelle_1 t1
WHERE t1.spalte1 NOT IN (SELECT t2.spalte1 FROM tabelle_2 t2)
ORDER BY spalte1
Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische Systemkataloge l�dt, ist eine datenbank�bergreifende Abfrage nicht m�glich.
contrib/dblink ist eine Erweiterung, die datenbank�bergreifende Abfragen erm�glicht.
Es ist nat�rlich m�glich, dass eine Client-Anwendung gleichzeitige Verbindungen zu verschiedenen Datenbanken aufbaut und selber Datens�tze zusammenf�gt.
Ab 7.3 unterst�tzt PostgreSQL schemas, die die Aufteilung einer Datenbank in mehrere logische Bereiche erm�glichen. Bei vielen Anwendungen k�nnten dies einen geeigneten Ersatz f�r den Zugriff auf eine andere Datenbank bieten.
Ab 7.3 k�nnen Funktionen mehrere Zeilen und Spalten zur�ckgeben, vgl.: http://techdocs.postgresql.org/guides/SetReturningFunctions.
PL/PgSQL verarbeitet die Inhalte einer Funktion in einer Cache. Dies hat eine unangenehme Nebenwirkung, n�mlich dass wenn eine PL/PgSQL- Funktion auf eine tempor�re Tabelle zugreift, und diese Tabelle anschlie�end gel�scht bzw. neu erstellt wird, die Funktion fehlschlagen wird, da die gecachte Funktionsinhalte noch auf die alte tempor�re Tabelle zeigen.
Die L�sung f�r diese Probleme besteht darin, in der Funktion mittels EXECUTE auf tempor�re Tabellen zuzugreifen. Diese bewirkt, dass bei jedem Funktionsruf die betreffende Abfrage von PL/PgSQL neu geparst wird.
Es existieren mehrere Ans�tze zur Master/Slave-Replikation in PostgreSQL. In diesen werden Daten�nderungen in der Master-Datenbank durchgef�hrt und an Slave-Datenbanken weitergeleitet. Informationen �ber diese L�sungen befinden sich auf der folgenden Seite (unten): http://gborg.PostgreSQL.org/genpage?replication_research .
Eine Multi-Master-L�sung befindet sich in der Entwicklung. N�heres dazu befindet sich hier: http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php .
Dieses Problem kann viele Ursachen haben. Testen Sie Ihre Funktion zuerst in einem eigenen Testprogramm.
Senden Sie Ihre Beitr�ge an die Mailing Liste pgsql-hackers, und sie werden nach Pr�fung eventuell ins contrib/ Verzeichnis des Quellcodes aufgenommen werden.
Ab PostgreSQL 7.3 werden Funktionen, die Tupel zur�ckliefern, in C, PL/PgSQL und SQL unterst�tzt. Der Programmer's Guide enth�lt weitere Informationen dazu. Ein Bespiel einer solchen Funktion befindet sich in contrib/tablefunc.
Die Makefiles enthalten nicht die richtigen Abh�ngigkeiten f�r include- Dateien. Sie m�ssen ein "make clean" und dann ein weiteres "make" ausf�hren. Wenn Sie gcc benutzen, k�nnen Sie die "--enable-depend"-Option des configure- Skripts benutzen, damit der Compiler die Abh�ngigkeiten automatisch ermittelt.
Die englische Vorlage dieser FAQ wird st�ndig �berarbeitet. Daher liegt die �bersetzung nicht immer auf dem aktuellsten Stand.
Die aktuellste Version der deutschen �bersetzung befindet sich immer unter http://sql-info.de/postgresql/FAQ_german.html. Diese "Arbeitsversion" enth�lt eventuell �nderungen, die noch nicht auf der PostgreSQL-Website eingebunden worden sind.
�ber Verbesserungshinweise und Korrekturvorschl�ge sowie Verst�ndnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf die Mailing-Listen als schnelle und zuverl�ssige Anlaufstellen.
Diese �bersetzung basiert teilweise auf einer fr�heren �bersetzung von Karsten Schulz (schulz@linux-systemhaus.de).