Index: FAQ_german.html =================================================================== RCS file: /projects/cvsroot/pgsql-server/doc/src/FAQ/FAQ_german.html,v retrieving revision 1.4 diff -c -r1.4 FAQ_german.html *** FAQ_german.html 2001/08/24 14:07:48 1.4 --- FAQ_german.html 2002/10/22 03:55:39 *************** *** 1,1136 **** ! !
!! Last updated: Sat Jul 10 00:37:57 EDT 1999 !
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
!
! Deutsche Übersetzung von Karsten Schulz (schulz@linux-systemhaus.de)
!
! Letzte Aktualisierung der deutschen Übersetzung: Don, den 05.08.1999, 09:00 CET !
! Die aktuellste Version dieses Dokuments kann auf der PostgreSQL Website http://www.PostgreSQL.org angesehen werden. !
! Linux-spezifische Fragen werden in http://www.PostgreSQL.org/docs/faq-linux.html ! beantwortet (deutsche Übersetzung in Arbeit!).
! Irix-spezifische Fragen werden in http://www.PostgreSQL.org/docs/faq-irix.html beantwortet. !
! HPUX-spezifische Fragen werden in http://www.PostgreSQL.org/docs/faq-hpux.shtml beantwortet. !
!
! !
! ! PostgreSQL ist eine Verbesserung des POSTGRES-Datenbank-Managementsystems, ein ! "Next-Generation" DBMS-Forschungsprototyp. Während PostgreSQL das leistungsfähige Datenmodell und ! die reichhaltigen Datentypen von POSTGRES beibehält, ersetzt es die PostQuel-Abfragesprache durch ! eine ausgedehnte Teilmenge von SQL. PostgreSQL ist frei und der komplette Quellcode ist verfügbar. !
! ! Die PostgreSQL-Entwicklung wird von einem Team von Internet-Entwickler durchgeführt, die alle an ! der PostgreSQL-Entwicklungs-Mailingliste teilnehmen. Der aktuelle Koordinator ist Marc G. Fournier ! (scrappy@postgreSQL.org) (siehe unten, wie ! man sich anmelden kann). Dieses Team ist jetzt für alle aktuellen und zukünftigen Entwicklungen von PostgreSQL ! verantwortlich. ! !
! ! ! Die Autoren von PostgreSQL 1.01 waren Andrew Yu und Jolly Chen. Viele andere haben zur Portierung, ! zu den Tests, zur Fehlersuche und zur Verbesserung des Codes beigetragen. ! Der ursprüngliche Postgres-Code, von dem PostgreSQL abstammt, ist auf die Bemühungen von ! vielen Studierenden und Diplomanden, sowie Programmierern, die unter ! der Weisung des Professors Michael Stonebraker an der Universität von Kalifornien, Berkeley ! arbeiteteten, zurückzuführen. ! !
! ! Der ursprüngliche Name der Software bei Berkeley war Postgres. Als die SQL-Funktionalität 1995 ! hinzugefügt wurde, wurde sein Name zu Postgres95 geändert. Der Name wurde Ende 1996 zu ! PostgreSQL geändert. !
! !
! ! PostgreSQL steht unter folgendem COPYRIGHT (Originaltext):
! ! PostgreSQL Data Base Management System
! ! 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.
!
! Es gilt die Copyright-Klausel im Original! Informativ folgt hier eine
! Übersetzung. Die Übersetzung besitzt keinerlei rechtlichen Status.
! Insbesondere kann sich niemand auf diese Übersetzung berufen:
!
! ! PostgreSQL Datenbank Management System
! ! Copyright (c) 1994-6 Regents of the University of California
! ! Die Erlaubnis, diese Software und seine Unterlagen für jeden möglichen Zweck, ohne Gebühr und ohne ! eine schriftliche Vereinbarung zu benutzen, zu kopieren, zu ändern und zu verteilen wird hiermit ! bewilligt, vorausgesetzt daß der oben genannte Urheberrechtsvermerk und dieser Paragraph und die ! folgenden zwei Paragraphen in allen Kopien erscheinen.
! ! IN KEINEM FALL IST DIE UNIVERSITÄT VON KALIFORNIEN GEGENÜBER JEDEM MÖGLICHEN BETEILIGTEN FÜR DIE DIREKTEN, ! INDIREKTEN, SPEZIELLEN, BEILÄUFIGEN ODER FOLGESCHÄDEN, EINSCHLIEßLICH DER VERLORENEN PROFITE ! VERANTWORTLICH, DIE AUS DEM GEBRAUCH VON DIESER SOFTWARE UND SEINEN UNTERLAGEN ! HERAUS ENTSTEHEN, SELBST WENN DIE UNIVERSITÄT VON KALIFORNIEN VON DER MÖGLICHKEIT SOLCHEN SCHADENS ! BENACHRICHTIGT WORDEN IST.
! ! DIE UNIVERSITÄT VON KALIFORNIEN LEHNT SPEZIELL ALLE MÖGLICHE GARANTIEN AB, ! EINSCHLIESSLICH, ABER NICHT BEGRENZT AUF, DIE IMPLIZIERTEN GARANTIEN VON ! GESCHÄFTSNUTZEN UND EIGNUNG ZU EINEM BESTIMMTEN ZWECK. DIE SOFTWARE, DIE ! NACHSTEHEND BEREITGESTELLT WIRD, BASIERT AUF EINER "SO WIE SIE IST"-GRUNDLAGE, UND DIE UNIVERSITÄT ! VON KALIFORNIEN HAT KEINE VERPFLICHTUNGEN, WARTUNG, SUPPORT, ! AKTUALISIERUNGSVORGÄNGE, VERBESSERUNGEN ODER ÄNDERUNGEN ZUR VERFÜGUNG ! ZU STELLEN. ! !
! ! Die Autoren haben PostgreSQL auf folgenden Plattformen kompiliert und getestet ! (einige dieser Kompilierungen benötigen den C-Compiler gcc): !
! !
! ! Es ist möglich, die libpq C-Bibliothek, psql und andere Schnittstellen und Binaries zu ! kompilieren, um sie auf der MS-Windows-Plattform laufen zu lassen. ! In diesem Fall läuft der Client auf MS-Windows und steht über TCP/IP mit einem ! Server in Verbindung, der auf einer unserer unterstützten Unixplattformen läuft. ! ! Es gibt die Datei win31.mak in der Distribution, um die Win32 libpq-Bibliothek und psql ! zu erzeugen.
! ! Der Datenbankserver arbeitet jetzt auch unter Benutzung der Cygnus Unix/NT-Porting-Bibliotheken ! auf Windows NT. Siehe auch pgsql/doc/README.NT in der Distribution.
! ! Es gibt eine weitere Portierung, die U/Win benutzt bei http://surya.wipro.com/uwin/ported.html. ! ! !
! Die erste Anlaufadresse für PostgreSQL ist der ftp-Server ftp://ftp.postgreSQL.org/pub !
! ! Die entsprechenden Spiegelserver sind auf der Hauptwebseite aufgelistet. ! !
! ! Es gibt keinen offiziellen Support für PostgreSQL von der Universität von Kalifornien, Berkeley. Der ! Support wird durch freiwilligen Einsatz geleistet. !
! ! Die Mailing-Liste ist: pgsql-general@postgreSQL.org. ! Die Liste ist für PostgreSQL betreffende Themen vorbehalten. Um sich anzumelden, sende eine ! Email mit folgenden Zeilen im Text (nicht in der Betreffzeile): ! !
!
! subscribe
! end
!
!
! ! an pgsql-general-request@postgreSQL.org.
! ! Es gibt auch eine Digest-Liste (Eine Liste, die Mails zusammengefasst sendet). ! Um sich an dieser Digestliste anzumelden, sende eine Email an: ! pgsql-general-digest-request@postgreSQL.org ! mit folgendem Text: ! !
!
! subscribe
! end
!
!
!
! Die Digests werden an die Mitglieder der Liste geschickt, wenn ca. 30kB an Mails
! zusammengekommen sind.! ! Die Bug-Mailingliste ist verfübar. Um sich an dieser Liste anzumelden, ! sende eine Email an bugs-request@postgreSQL.org ! mit folgendem Text:
! !
!
! subscribe
! end
!
!
!
! Es gibt ebenfalls eine Entwickler-Diskussionsliste. Um sich an dieser Liste anzumelden,
! sende eine Email an hackers-request@postgreSQL.org
! mit diesem Text:! !
!
! subscribe
! end
!
!
! ! Weitere Mailinglisten und Informationen zu PostgreSQL können auf der PostgreSQL-Homepage im WWW ! gefunden werden: !
! http://postgreSQL.org !
!
! Es gibt außerdem einen IRC-Channel im EFNet, Kanal #PostgreSQL.
! Bruce nutzt den Unix-Befehl: irc -c '#PostgreSQL' "$USER" irc.phoenix.net
um teilzunehmen
! ! Kommerzieller Support für PostgreSQL ist bei http://www.pgsql.com/ verfügbar
! ! !
! ! Das neueste Release von PostgreSQL ist die Version 6.5.
! ! Wir planen alle 4 Monate Hauptreleases herauszugeben.
! ! !
! ! Einige Handbücher, Man-Pages und einige kleine Testprogramme sind in der Distribution enthalten. ! Siehe im /doc-Verzeichnis.
! ! psql ! hat einige nette \d-Befehle, um Informationen über Typen, Operatoren, Funktionen, Aggregate, usw. zu zeigen.
! ! Die Website enthält sogar noch mehr Unterlagen.
! !
! ! ! PostgreSQL unterstützt eine ausgedehnte Untermenge von SQL-92. ! Siehe unser TODO ! für eine Auflistung der bekannten Fehler, fehlende Eigenschaften und zukünftige Pläne.
! ! !
! ! Es gibt nette SQL-Tutorials bei ! http://w3.one.net/~jhoffman/sqltut.htm und bei ! http://ourworld.compuserve.com/homepages/Graeme_Birchall/DB2_COOK.HTM.
! ! Viele unserer User mögen The Practical SQL Handbook, Bowman et al., ! Addison Wesley.
! ! !
! ! Ja, wir können Datumsangaben nach dem Jahr 2000 n.Chr. und vor 2000 v.Chr. leicht ! verarbeiten.
! !
! ! Zuerst lade die neuesten Quellen herunter und lies die PostgreSQL-Entwicklerunterlagen ! auf unserer Website oder in der Distribution. Zweitens melde Dich zu den Mailinglisten ! pgsql-hackers und pgsql-patches an. Drittens sende qualitativ hochwertige Programmänderungen ! an die pgsql-patches Mailingliste.
! ! Es gibt ungefähr ein Dutzend Leute, die das commit-Recht im PostgreSQL-CVS Archiv haben. ! Alle haben so viele hochwertige Patches eingebracht, daß es schwer für die ! CVS-Verwalter war, mitzuhalten. Und wir hatten das Vertrauen, daß ! die Änderungen, die sie festlegten, sehr wahrscheinlich von hoher Qualität sind.
! !
! ! Fülle die "Fehler-Vorlage"-Datei (bug.template im doc-Verzeichnis) aus und sende sie an: ! bugs@postgreSQL.org
! ! Ü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.
! !
! !
! ! Im no-fsync-Modus sind wir normalerweise schneller als kommerzielle Datenbanken. In ! diesem Modus kann ein Betriebssystemabsturz jedoch Datenkorruption zur Folge haben. ! Wir arbeiten daran, einen Zwischenmodus zur Verfügung zu stellen, der unter weniger Leistungseinbuße ! leidet als der fsync-Modus und die Datenintegrität innerhalb 30 Sekunden ! im Falle eines Betriebssystemabsturzes erlaubt. Der Modus ist durch den Datenbankverwalter ! auswählbar.
! ! Im Vergleich zu MySQL oder schlankeren Datenbanksystemen sind wir hinsichtlich INSERTs/UPDATEs langsamer, ! weil wir einen Transaktions-Overhead haben. ! Selbstverständlich hat MySQL kaum eine der Eigenschaften, die oben im Kapitel Eigenschaften erwähnt werden. ! PostgreSQL ist für Flexibilität und gute Eigenschaften designed, trotzdem fahren wir fort, ! die Leistung durch Profiling und Quellcodeanalyse zu verbessern.
! ! ! !
! !
! !
! ! Es sind zwei ODBC-Treiber verfügbar: PostODBC und OpenLink ODBC.
! ! PostODBC ist in der Distribution enthalten. Mehr Informationen können unter ! http://www.insightdist.com/psqlodbc abgerufen werden.
! ! OpenLink ODBC kann unter http://www.openlinksw.com ! geholt werden. ! Die Software arbeitet mit OpenLinks Standard-ODBC-Client, so daß PostgreSQL-ODBC auf ! jeder Client-Plattform zur Verfügung steht, die unterstützt wird (Win, Mac, Unix, VMS).
! ! Sie werden dieses Produkt wahrscheinlich an Leute verkaufen, die kommerziellen Qualitäts-Support ! brauchen, aber es 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.webtools.com abgerufen werden.
! ! Eine weitere gibt es bei ! http://www.phone.net/home/mwm/hotlist/.
! ! Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. ! PHP gibt es bei http://www.php.net
! ! PHP ist hervorragend für einfache Anbindungen geeignet. Für komplexere ! Aufgaben nutzen viele die Perl-Schnittstelle mit CGI.pm.
! ! Einen WWW-Gateway, basierend auf WDB, kann man bei ! http://www.eol.ists.ca/~dunlop/wdb-p95 herunterladen. ! !
! ! Wir haben eine nette grafische Benutzerschnittstelle mit Namen ! pgaccess, welche in der Distribution enthalten ist. ! pgaccess hat auch einen Reportgenerator. Die Webpage liegt hier: ! http://www.flex.ro/pgaccess
! ! In der Distribution gibt es außerdem ecpg,, ! welches eine eingebundene SQL-Query-Schnittstelle für C zur Verfügung stellt. ! ! !
! ! Wir haben: !
! !
! ! !
! !
NOTICE:heap_modifytuple: repl is \ 9
, ist das das Problem.)
! ! ! !
! ! Der einfachste Weg ist mittels der --prefix Option beim configure den Pfad anzugeben. ! Falls Du das vergessen haben solltest, kannst Du die Datei Makefile.global ändern und ! POSTGRESDIR entsprechend anpassen, oder Du erzeugst ein Makefile.custom und definierst POSTGRESDIR dort. !
! ! !
! ! Das kann verschiedene Ursachen haben. Überprüfe zuerst, ob Dein Kernel System V Extensions ! enthält. PostgreSQL benötigt die Kernel-Unterstützung für Shared Memory und Semaphoren. !
! ! !
! ! Du hast entweder den Kernel nicht für Shared Memory konfiguriert, oder Du mußt den ! Shared Memory Bereich vergrößern. ! Die genaue Größe hängt von Deiner Systemarchitektur ab und mit wievielen ! Puffern und Serverprozessen Du postmaster konfiguriert hast. ! Für die meisten Systeme, mit Standardangaben für Puffer und Prozessen benötigst ! Du ein Minimum von ca. 1 MB. ! ! !
! ! Falls die Fehlermeldung IpcSemaphoreCreate: semget failed (No space ! left on device) lautet, dann ist Dein Kernel mit zu wenig Semaphoren konfiguriert. ! ! Postgres benötigt eine Semaphore pro möglichen Backend-Prozess. ! Eine Zwischenlösung wäre, postmaster mit einer geringeren Anzahl an Backend-Prozessen zu starten. ! Benutze dazu die -N Option mit einem Wert kleiner als die standardmäßigen 32. ! ! Eine dauerhafte Lösung wäre es, die Kernel-Parameter ! SEMMNS und SEMMNI zu erhöhen.
! ! Falls die Fehlermeldung anders aussieht, hast Du möglicherweise keine Semaphoren-Unterstützung ! in Deinem Kernel aktiviert.
! ! !
! ! Die Standardeinstellung ist, daß PostgreSQL Verbindungen von der lokalen Maschine über ! Unix-Domain-Sockets erlaubt. Andere Maschinen werden keine Verbindung aufbauen können, bis ! der postmaster mit der -i Option gestartet ist und die Host-basierte Authentizierung ! in der Datei $PGDATA/pg_hba.conf entsprechend angepasst ist. ! Das erlaubt TCP/IP-Verbindungen. !
! !
! ! Die Standardeinstellung erlaubt nur Unix-Domain-Socket-Verbindungen der lokalen Maschine. ! Um TCP/IP Verbindungen zu ermöglichen, stelle sicher, daß der postmaster ! mit der -i Option gestartet wurde, und füge einen passenden Host-Eintrag in die Datei ! pgsql/data/pg_hba.conf ein. Siehe auch die pg_hba.conf Man-Page.
! ! !
! ! Du solltest keine Datenbank-Benutzer mit der User-ID 0 (root) erzeugen. ! Sie werden auf keine Datenbank zugreifen können. Das ist eine Sicherheitsmaßnahme, ! wegen der Möglichkeit Objekt-Module dynamisch in die Datenbank zu linken. !
! ! !
! ! Dieses Problem kann durch einen Kernel verursacht werden, der ohne Support für Semaphoren ! konfiguriert wurde. ! ! !
! ! Sicherlich können Indizes Abfragen beschleunigen. Der explain Befehl ! erlaubt Dir zu sehen, wie PostgreSQL Deine Abfrage interpretiert und welche Indizes ! benutzt werden. !
! ! Wenn Du eine Menge INSERTs machst, überprüfe, ob Du sie als Stapelverarbeitung ! mit dem copy-Befehl abarbeiten kannst. ! Das ist viel schneller als einzelne INSERTs. ! ! Zweitens, SQL-Statements, die nicht in einem begin work/commit Transaktions-Block eingegeben werden, ! werden als eigene Transaktion behandelt. Überprüfe, ob die Statements nicht ! in einen einzelnen Transaktions-Block zusammengefasst werden können. Das reduziert den Transaktions-Overhead. ! ! Du kannst auch erwägen, Indizes zu löschen und neu zu erstellen, wenn Du große ! Datenmengen änderst.
! ! Es gibt verschiedene Tuning-Maßnahmen, die man ergreifen kann. ! Du kannst fsync() abschalten, indem Du beim Starten des postmasters die Optionen -o -F angibst. ! Das hindert fsync()´s daran, nach jeder Transaktion die Daten auf die Platte zu schreiben. ! ! Du kannst auch mit der -B Option des postmasters die Anzahl der Shared Memory Puffer für den Backend-Prozess erhöhen. ! Falls Du diesen Wert zu hoch einstellst, kann es sein, daß der postmaster nicht startet, weil ! der Shared Memory Speicherplatz Deines Kernels aufgebraucht wird. ! Jeder Puffer ist 8 kB groß und es gibt standardmäßig 64 Puffer.
! ! Du kannst ebenfalls 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. Es wäre ! jedoch unklug, den Wert zu hoch anzugeben, da ein Query möglicherweise Speicherplatzmangel verursacht, ! wenn es viele gleichzeitige Sortierungen durchführen muß.
! ! Der cluster Befehl kann benutzt werden, um Daten in Basistabellen zu gruppieren, so daß sie ! auf einen Index zusammengebracht werden. Siehe auch die cluster(l) Man-Page für weitere Details. ! ! !
! ! PostgreSQL hat einige Möglichkeiten, Statusinformationen zu berichten, die ! nützlich für die Fehlersuche sein können.
! ! Erstens, wenn beim configure-Lauf die Option --enable-cassert angegeben wurde, ! verfolgen viele assert()´s den Fortschritt des Backends und halten das Programm ! an, wenn etwas Unerwartetes passiert. !
! ! Postmaster und postgres, haben mehrere Fehlersuch-Optionen zur Verfügung. ! Stelle zuerst sicher, daß Du den Standard-Output und Fehlerkanal in eine Datei umleitest, wenn Du den postmaster startest, : !
!
! cd /usr/local/pgsql
! ./bin/postmaster >server.log 2>&1 &
!
!
! ! Das erzeugt eine server.log Datei im PostgreSQL-Verzeichnis. ! 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-Level erzeugen schnell große Logdateien! !
! ! Du kannst tatsächlich das Postgres-Backend auf der Kommandozeile ! laufen lassen und SQL-Statements direkt eingeben. ! Diese Vorgehensweise wird aber nur zur Fehlersuche empfohlen. ! Beachte, daß ein Zeilenumbruch das SQL-Statement beendet, nicht das Semikolon. ! Wenn Du PostgreSQL mit Debugging-Symbolen kompiliert hast, kannst Du einen Debugger ! benutzen, um zu beobachten, was passiert. ! Da das Backend nicht vom postmaster gestartet wurde, läuft es nicht in der ! gleichen Umgebung und deshalb können einige locking/backend Operationen ! nicht reproduziert werden. ! Einige Betriebssysteme können sich an einen Backend-Prozess direkt ! anhängen, um Probleme zu diagnostizieren. !
! ! Das Programm postgres hat -s, -A und -t Optionen, die bei der Fehlersuche ! und Leistungsmessung sehr nützlich sein können. ! ! Du kannst das Paket 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. !
! ! !
! ! Du mußt die Grenze des postmasters, die festlegt, ! wieviele gleichzeitige Backend-Prozesse gestartet werden können, hochsetzen.
! ! In Postgres 6.5 sind das normalerweise 32 Prozesse. Du kannst diesen Wert dadurch erhöhen, ! daß Du den postmaster mit einem entsprechenden -N Wert neu startest. ! In der Standardkonfiguration kannst Du -N auf maximal 1024 setzen. ! Falls Du mehr brauchst, erhöhe MAXBACKENDS in include/pg_config.h und ! kompiliere das Paket neu. ! Du kannst den Standardwert von -N während der Konfiguration ! setzen, indem Du --with-maxbackends angibst. ! ! Anmerkung: Falls Du -N größer als 32 einstellst, solltest ! Du -B auf einen Wert, höher als 64 setzen. ! Für eine hohe Anzahl an Backend-Prozessen, solltest Du möglicherweise einige ! Unix-Kernel Parameter ebenfalls erhöhen. ! Folgendes Parameter solltest Du prü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. ! ! Der Grund für die Begrenzung der erlaubten Backend-Prozesse liegt darin, daß ! verhindert werden soll, daß das System seine freien Ressourcen aufbraucht. !
! ! In den Postgres-Versionen vor 6.5 war die maximale Anzahl von Backends auf ! 64 festgelegt und eine Änderung setzte eine erneute Kompilierung voraus, ! bei der die Konstante MaxBackendId in include/storage/sinvaladt.h. ! entsprechend angepasst wurde.
! !
! ! Dies sind temporäre Dateien, die durch den Query-Ausführer erzeugt werden. ! Wenn zum Beispiel eine Sortierung durchgeführt werden muß, um ein ORDER BY ! auszuführen, und diese Sortierung mehr Platz benötigt, als mit dem Backend-Parameter -S ! erlaubt wurde, dann werden diese temporären Dateien erzeugt, um die Daten dort zu halten. !
! ! Die temporären Dateien sollten automatisch gelöscht werden, falls das Backend jedoch ! während einer Sortierung abstürzt, bleiben sie erhalten. ! Wenn zu diesem Zeitpunkt keine Transaktion läuft, kannst Du die ! pg_tempNNN.NN Dateien ohne Gefahr löschen.
! !
! ! Zur Zeit gibt es keine einfache Schnittstelle, um Benutzergruppen einzurichten ! Du mußt explizit die pg_group-Tabelle mittels INSERT/UPDATE modifizieren. ! Zum Beispiel: ! !
!
! jolly=> INSERT into pg_group (groname, grosysid, grolist)
! jolly=> values ('posthackers', '1234', '{5443, 8261}');
! INSERT 548224
! jolly=> grant INSERT on foo to group posthackers;
! CHANGE
! jolly=>
!
!
! ! Die Felder in pg_group sind: !
! ! !
! ! !
! ! Überprüfe die Konfiguration Deiner Locale-Einstellung. PostgreSQL benutzt die ! Einstellungen des jeweiligen Users und nicht die des postmaster Prozesses. ! Es gibt postgres und psql SET Befehle, um das Datumsformat zu kontrollieren. ! Setzte diese entsprechend Deiner Arbeitsumgebung. !
! ! !
! ! Vgl. die declare Man-Page für eine Beschreibung.
! !
! ! Vgl. die fetch Man-Page, oder benutze SELECT ... LIMIT....
! ! Das verhindert nur, daß alle Ergebniszeilen zum Client übermittelt werden. ! Die komplette Abfrage muß abgearbeitet werden, selbst wenn Du nur die ersten paar Zeilen haben möchtest. ! Ziehe ein Query in Erwägung, das ein ORDER BY benutzt. Es gibt keine Möglichkeit Zeilen ! zurückzuliefern, bevor nicht die komplette Abfrage abgearbeitet ist. !
! !
! ! Du kannst Dir die Datei pgsql/src/bin/psql/psql.c mit dem Quellcode für psql ansehen. ! Sie enthält die SQL-Befehle, die die Backslash-Kommandos (\) ausführen. ! Seit Postgres 6.5 kannst Du psql auch mit der -E Option starten. Dadurch gibt ! psql die Queries aus, die es bei der Ausführung der Befehle benutzt. !
! ! !
! ! Wir unterstützen alter table drop column nicht, aber mache es so: !
! SELECT ... -- wähle alle Spalten außer die, die Du entfernen willst
! INTO TABLE new_table
! FROM old_table;
! DROP TABLE old_table;
! ALTER TABLE new_table RENAME TO old_table;
!
!
! ! !
! ! Zeilen sind auf 8 kB begrenzt, aber das kann geändert werden, indem Du in ! include/config.h die Konstante BLCKSZ änderst. ! Um Attribute mit mehr als 8 kB zu nutzen, kannst Du auch das "Large Object Interface" benutzen.
! Zeilen überschreiten keine 8 kB-Grenzen. Eine Zeile mit 5 kB wird 8 kB Speicherplatz benötigen. !
! ! Tabellen- und Datenbankgrößen haben keine Grenzen. Es gibt viele Datenbanken mit zig Gigabytes und ! wahrscheinlich einige mit hunderten Gigabyte. ! !
! ! Eine Postgres Datenbank kann ungefähr sechseinhalb mal soviel Platz brauchen, ! wie eine einfache Textdatei.
! ! Betrachten wir eine Datei mit 300.000 Zeilen, mit jeweil zwei Integern pro Zeile. ! Die einfache Textdatei benötigt 2,4 MB Speicherplatz. ! Die Größe der Postgres Datenbankdatei, die diese Daten enthält, liegt ! ungefähr bei 14 MB. ! !
! 36 Bytes: jeder Zeilenkopf (ungefähr) ! + 8 Bytes: zwei Integer-Felder @ jedes 4 Bytes ! + 4 Bytes: Zeiger auf den Datensatz ----------------------------------------------- ! 48 Bytes pro Zeile ! ! Die Größe einer Datenseite in PostgreSQL ist 8192 Bytes (8 KB), also: ! 8192 Bytes pro Seite ! --------------------- = 171 Zeilen pro Seite (aufgerundet) ! 48 Bytes pro Zeile ! ! 300000 Datenzeilen ! ----------------------- = 1755 Datenbankseiten ! 171 Zeilen pro Seite ! ! 1755 Datenbankseiten * 8192 Bytes pro Seite = 14,376,960 Bytes (14MB) !! ! Indizes haben nicht einen solchen Overhead, sie beinhalten jedoch die Daten, die sie ! indizieren und können so auch sehr groß werden. !
! !
! ! psql hat eine Vielzahl von Backslash Befehlen, um solche Informationen zu zeigen. ! Benutze \?, um sie zu sehen. !
! ! Schaue Dir auch die Datei pgsql/src/tutorial/syscat.source. an. ! Sie illustriert viele der SELECTs, die benötigt werden, um diese Informationen ! von der Datenbank-Systemtabelle zu erhalten !
! ! !
! ! PostgeSQL pflegt automatische Statistiken nicht. ! Um die Statistiken zu aktualisieren, mußt Du ein explizites vacuum eingeben. ! Nach dieser Aktualisierung weiß der Optimierer ! wieviele Zeilen in der Tabelle sind und kann besser entscheiden, ob Indizes benutzt werden sollten. ! Der Optimierer benutzt keine Indizes, wenn die Tabelle klein ist, weil ein sequentieller Suchlauf ! dann schneller sein würde.
! ! Benutze den Befehl vacuum analyze für die spaltenspezifische Optimierung. ! Vacuum analyze ist für komplexe Multi-Join-Abfragen wichtig, damit der Optimierer ! die Anzahl der Zeilen von jeder Tabelle schätzen und dann die passende Join-Reihenfolge ! wählen kann. ! Das Backend verfolgt die Spaltenstatistik nicht selbst, so daß vacuum analyze ! regelmäßig aufgerufen werden sollte. !
! ! Indizes werden nicht für ORDER BY Operationen benutzt.
! ! Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indizes ! nur benutzt werden, wenn die Suche mit dem Anfang eines Strings startet. ! Um also Indizes zu nutzen, sollten LIKE-Suchen nicht mit ! %, und ~ beginnen (Die Sucheparameter regulärer Ausdrücke sollten ! mit ^. beginnen. ! !
! ! 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.
! ! Du kannst dieses Werk ebenfalls in Stonebraker's "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 ! Joining vieler Tabellen auf der Basis genetischer Algorithmen (GA) zu lösen. ! Es erlaubt die Behandlung von großen Join-Queries ohne erschöpfende Suche. !
! Für weitere Informationen siehe die Dokumentation. ! ! !
! ! ~ und ~* sind wahrscheinlich das, was Du willst. ! Vgl. psql's \do Befehl.
! ! !
! ! Du testest die Spalte mit IS NULL und IS NOT NULL.
! ! !
! Typ interner Name Bemerkungen ! -------------------------------------------------- ! CHAR char 1 Zeichen ! CHAR(#) bpchar mit Leerzeichen gefüllt bis zur angegebenen Länge ! VARCHAR(#) varchar Die Größe legt die Maximallänge fest, kein Ausfüllen mit Leerzeichen ! TEXT text Die Länge wird nur durch die maximale Zeilenlänge beschränkt ! BYTEA bytea Bytearray mit variabler Länge !
! ! Du mußt die internen Namen benutzen, wenn Du interne Operationen durchführen willst. !
! ! Die letzten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes geben die Länge an, gefolgt ! von den Daten). ! CHAR(#) belegt die maximale Anzahl von Bytes, unabhängig davon, wieviele Daten im ! Feld gespeichert werden. ! TEXT, VARCHAR(#) und BYTEA haben alle eine variable Länge auf dem Datenträger, ! deshalb gibt es einen leichten Geschwindigkeitsnachteil bei der Nutzung dieser Typen. ! Genauer, der Nachteil gilt für den Zugriff auf alle Spalten nach der ersten Spalte dieses Typs. !
! ! !
! ! PostgreSQL unterstützt einen SERIAL Datentyp. Er erzeugt automatisch eine ! Sequenz und einen Index auf die Spalte. Siehe die create_sequence Man-Page ! für weitere Informationen über Sequenzen. ! ! Du kannst aber auch das Oid Feld jeder Zeile als eindeutigen Wert nutzen. ! Jedoch mußt Du, falls Du Deine Datenbank einmal komplett ausgeben und wieder einlesen willst, ! die pg_dump's -o oder die copy with oids Option benutzen, um die Oids zu retten.
! !
! ! Oids sind PostgreSQLs Antwort auf eindeutige Zeilen-IDs. Jede Zeile, die in PostgreSQL ! erzeugt wird, bekommt eine eindeutige Oid. Alle Oids, die während initdb erzeugt werden, sind kleiner ! als 16384 (nach backend/access/transam.h). ! Alle Oids, die durch den Benutzer erzeugt werden, sind gleich oder größer als dieser Wert. ! Standardmäßig sind all diese Oids nicht nur innerhalb einer Tabelle oder Datenbank, sondern ! in der gesamten PostgreSQL Installation eindeutig. !
! PostgreSQL benutzt Oids in seinen internen Systemtabellen, um Zeilen zwischen den Tabellen zu ! verbinden. Diese Oids können zur Identifikation spezifischer Benutzerzeilen und in Joins ! genutzt werden. ! Es wird empfohlen, den Spaltentyp OID zu nutzen, um Oids-Werte zu speichern. ! Siehe die sql(l) Man-Page, um die anderen internen Spalten kennenzulernen. ! Du kannst einen Index auf ein Oid-Feld erzeugen, um schnelleren Zugriff zu erreichen. !
! ! Oids werden allen neuen Zeilen von einem zentralen Bereich, der von allen Datenbanken ! genutzt wird, zugewiesen. Es gibt keinen Grund, warum Du nicht die Oid ändern, oder eine Kopie der ! Tabelle mit den originalen Oids anlegen könntest. !
! 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'; ! !
! ! Tids werden genutzt, um spezifische physische Zeilen mit Block und ! Versatzwert zu identifizieren. Tids ändern sich, wenn Zeilen geändert oder ! neu geladen werden. Sie werden von Index-Einträgen genutzt, um die ! Zeilen physisch zu adressieren. ! !
! ! Einige der Quelltexte und die ältere Dokumentation nutzen allgemeine Begriffe. ! Hier sind einige aufgeführt: ! !
! !
! ! Möglicherweise ist der virtuelle Speicher verbraucht oder Dein Kernel hat ! eine niedrige Grenze für bestimmte Ressourcen. ! Versuche dieses, bevor Du den postmaster startest: ! !
!
! ulimit -d 65536
! limit datasize 64m
!
!
!
! Je nach Deiner eingesetzten Shell mag nur einer dieser Befehle funktionieren.
! Aber es wird die Grenze des Datensegments für Prozesse erhöhen und vielleicht
! läuft so Dein Query durch.
! Dieser Befehl wirkt sich auf den aktuellen Prozess und alle seine Unterprozesse
! aus, die nach diesem Befehl gestartet werden. Falls Du ein Problem mit dem SQL-CLient hast,
! weil das Backend zu viele Daten zurückliefert, versuche diesen Befehl, bevor Du den
! SQL-Client startest.
! ! !
!
! Gib in psql SELECT version();
ein
! !
!
! Du solltest die Befehle BEGIN WORK
und COMMIT
!
bei jeden Gebrauch von Large Objects benutzen. Also um
! lo_open
... lo_close.
! ! Die Dokumentation hat schon immer darauf hingewiesen, daß ! lo_open in eine Transaktion eingebunden werden muß, aber die PostgreSQL Versionen vor 6.5 ! haben diese Regel nicht erzwungen. ! Statt dessen scheiterten sie gelegentlich, wenn Du diese Regel gebrochen hattest.
! ! Das aktuelle PostgreSQL erzwingt diese Regel, indem es die Handles der Large Objects ! beim COMMIT der Transaktion schließt, was sofort nach dem lo_open passiert, ! wenn Du nicht innerhalb einer Transaktion bist. ! So führt der erste Versuch, etwas mit dem Large Object zu machen zu einem ! invalid large obj descriptor. ! Also wird der Code, der bisher benutzt wurde, nun diese Fehlermeldung erzeugen, wenn Du ! keine Transaktionen benutzt hast. !
! Falls Du eine Client-Schnittstelle wie ODBC benutzt, kann es sein, daß Du
! auto-commit off
setzen mußt.
! !
! ! !
! ! Dieses Problem kann viele Ursachen haben. Teste deine Funktion zuerst in einem ! Extra-Testprogramm. Stelle außerdem sicher, daß Deine Funktion nicht etwa elog-Nachrichten sendet, wenn der Client Daten erwartet, ! wie in den type_in() oder type_out() Funktionen
! ! !
! ! Du pfreest etwas, das Du nicht palloct hast! ! Stelle sicher, daß Du nicht malloc/free und palloc/pfree durcheinanderwürfelst. ! ! !
! ! Sende Deine Erweiterungen zur pgsql-hackers Mailing Liste, ! und sie werden eventuell im contrib/ Verzeichnis enden.
! ! !
! ! Das erfordert derart extreme Genialität, daß die Autoren es niemals versucht haben, ! obwohl es im Prinzip zu machen wäre.
! !
! ! Die Makefiles finden nicht die richtigen Abhängigkeiten. Du mußt ein make clean und dann ein weiteres make machen. ! ! --- 1,1306 ---- ! ! !
! !Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us).
!Deutsche Übersetzung von Ian Barwick (barwick@gmx.net).
! Basiert teilweise auf einer Übersetzung von Karsten Schulz (schulz@linux-systemhaus.de).
Letzte Aktualisierung der deutschen Übersetzung: Mo., den 21.10.2002, 23: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/users-lounge/docs/faq.html ! 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/faq-mswin.html.
! !Eine eigenständige Portierung auf MS Win NT/2000/XP befindet sich ! in Vorbereitung.
! !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 !! ! !
Weitere Mailinglisten und Informationen zu PostgreSQL befinden sich auf der PostgreSQL-Homepage:
!! http://www.PostgreSQL.org !!
Es gibt außerdem einen IRC-Channel im EFNet, 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://www.PostgreSQL.org/users-lounge/commercial-support.html ! eingesehen werden.
! !Die neueste Version von PostgreSQL ist 7.2.3.
! !Wir planen alle 4 Monate eine neue Version herauszugeben.
! !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/users-lounge/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://www.ca.PostgreSQL.org/books/ ! 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.
! !Es sind zwei ODBC-Treiber verfügbar: PsqlODBC und OpenLink ODBC.
! !PsqlODBC ist in der Distribution enthalten. Weitere Informationen können ! unter ftp://ftp.PostgreSQL.org/pub/odbc/ abgerufen werden.
! !OpenLink ODBC kann unter http://www.openlinksw.com geholt werden. Die ! Software arbeitet mit dem Standard-ODBC-Client der 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.
! !Bitte beachten Sie auch das Kapitel zu ODBC im Progammer's Guide.
! !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.
! !Wir haben eine nette grafische Benutzerschnittstelle namens ! PgAccess, der außerdem einen Reportgenerator enthält: ! http://www.pgaccess.org
! !Die Distribution enthält außerdem ecpg, die eine eingebettete ! SQL-Query-Schnittstelle für C zur Verfügung stellt.
! !PostgreSQL bietet:
!! !
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/idocs/index.php?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.
! !In den PostgreSQL-Versionen vor 6.5 war die maximale Anzahl von Backends ! auf 64 festgelegt und eine Änderung setzte eine erneute Kompilierung ! voraus, bei der die Konstante MaxBackendId in include/storage/sinvaladt.h ! entsprechend angepasst werden mußte. ! !
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.
! ! !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 erst 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; !! !
Es bestehen folgende Obergrenzen:
!! Maximale Größe eine Datenbank? unbeschränkt (es existieren ! Datenbanken mit >1TB) ! 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).
+ +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 + ------------------------------------------------- + "char" char 1 Zeichen + CHAR(n) bpchar mit Leerzeichen gefüllt bis zur angegebenen Länge + VARCHAR(n) varchar die Größe legt die Maximallänge fest; kein + Ausfüllen mit Leerzeichen + TEXT text Die Länge wird nur durch die maximale Zeilenlänge + beschränkt + BYTEA bytea Bytearray mit variabler Länge ++
Der interne Name kommt vor allem in den Systemkatalogen und in manchen + Fehlermeldungen vor.
+ +Die letzten 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.
+ +CHAR(n) ist geeignet für die Speicherung von Zeichenketten ähnlicher Länge. + VARCHAR(n) ist geeignet für Zeichenketten abweichender Längen, setzt jedoch + eine maximale Länge. TEXT setzt keine Längengrenze, allerdings gibt es + eine systembedingte Obergrenze von 1 GB. BYTEA ist für binäre Daten, + besonders für Werte, die NULL-Bytes haben. Die 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. + In Perl mit dem DBD::Pg-Modul von Edmund Mergl 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 + soll in einer künftigen PotsgreSQL-Version 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 ermöglicht datenbankübergreifende Abfragen.
+ +Es ist natürlich möglich, dass eine Client-Anwendung gleichzeitige Verbindungen + zu verschiedenen Datenbanken aufbaut und selber Datensätze zusammenfügt.
+ +"Result sets" können mittels refcursors von PL/PgSQL-Funktionen zurückgegeben + werden. Vgl.: + http://www.postgresql.org/idocs/index.php?plpgsql-cursors.html + (Abschnitt 23.7.3.3).
+ +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. + +
Über Verbesserungshinweise und Korrekturvorschläge sowie Verständnisfragen + zum Inhalt der FAQ freue ich mich. Ich nehme auch allgemeine Fragen zu PostgreSQL gerne + entgegen, kann aber leider keine zeitige Antwort garantieren.
! !