-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): -
+href="mailto:pgman@candle.pha.pa.us">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.
-Es gibt die Datei win31.mak in der Distribution, um die Win32 libpq-Bibliothek und psql -zu erzeugen.+
Eine hochwertige Infrastruktur ist für ein Open-Source-Projekt wie dieses + sehr wichtig. Sie verhindert Probleme und Verzögerungen beim Fortschritt des + Projekts.
-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.+
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.
-Es gibt eine weitere Portierung, die U/Win benutzt bei http://surya.wipro.com/uwin/ported.html. +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.
+-Die erste Anlaufadresse für PostgreSQL ist der ftp-Server ftp://ftp.postgreSQL.org/pub -
+
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.
-Es gibt keinen offiziellen Support für PostgreSQL von der Universität von Kalifornien, Berkeley. Der -Support wird durch freiwilligen Einsatz geleistet. -+
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).
-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): +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.
-
-
- subscribe
- end
-
-+
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.
-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: +Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. + PHP gibt es bei http://www.php.net
-
-
- subscribe
- end
-
-
+ Für komplexere Aufgaben bietet sich die Perl-Schnittstelle mit CGI.pm + oder mod_perl.
-Die Digests werden an die Mitglieder der Liste geschickt, wenn ca. 30kB an Mails -zusammengekommen sind.+
+
Wir haben eine nette grafische Benutzerschnittstelle namens + PgAccess, der außerdem einen Reportgenerator enthält: + http://www.pgaccess.org
-
-
- subscribe
- end
-
-
+ Die Distribution enthält außerdem ecpg, die eine eingebettete + SQL-Query-Schnittstelle für C zur Verfügung stellt.
-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
-
-+
PostgreSQL bietet:
+-http://postgreSQL.org -
+
irc -c '#PostgreSQL' "$USER" irc.phoenix.net um teilzunehmen+
+
+
+
+
+
-Einige Handbücher, Man-Pages und einige kleine Testprogramme sind in der Distribution enthalten. -Siehe im /doc-Verzeichnis.
+
+
Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis + angeben.
-Die Website enthält sogar noch mehr Unterlagen.+
+
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.
-Viele unserer User mögen The Practical SQL Handbook, Bowman et al., -Addison Wesley.+
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.
--Ja, wir können Datumsangaben nach dem Jahr 2000 n.Chr. und vor 2000 v.Chr. leicht -verarbeiten.
+
+
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.
-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 +3.6) Wie optimiere ich die Datenbank für bessere Leistung?
+ +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.
+ +3.7) Welche Debugging-Funktionen sind für PostgreSQL verfügbar?
+ +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.
+ +3.8) Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine + Verbindung augzubauen versuche. Warum?
+ +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. + +
3.9) Was befindet sich im Verzeichnis pgsql_tmp/?
+ +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.
+ +3.10) Warum muß ich bei jeder neuen Hauptversion von PostgreSQL + die komplette Datenbank exportieren und anschließend reimportieren?
+ +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.
+ +
+ +Fragen zum Betrieb
+ +4.1) Worin besteht der Unterschied zwischen Binary Cursors und Normal + Cursors?
+ +Vgl. die DECLARE Man-Page für eine Beschreibung.
+ +4.2) Wie wähle ich per SELECT-Anweisung nur die ersten paar + Zeilen in einer Abfrage aus?
+ +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.
+ + +4.3) Wie bekomme ich eine Liste der Tabellen oder anderen Dinge, die ich + in psql sehen kann?
+ +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.
+ +4.4) Wie entferne ich eine Spalte aus einer Tabelle?
+ +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; ++ +4.5) Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank?
+ +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.
+ +4.6) Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen + Textdatei abzuspeichern?
+ +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 ----------------------------------------------- - 48 Bytes pro Zeile - - Die Größe einer Datenseite in PostgreSQL ist 8192 Bytes (8 KB), also: - + 64 Bytes pro Zeile ++Die Größe einer Datenseite in PostgreSQL beträgt 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. -- -
4.8) Wie finde ich heraus, welche Indizes oder Operationen in der Datenbank definiert sind?
- -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 -
- - -
4.9) Meine Queries sind langsam oder nutzen die Indizes nicht. Warum?
- -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. - -
4.10) Auf welche Weise kann ich sehen, wie der Query-Optimierer meine Abfrage auswertet?
- -Vgl. die EXPLAIN Man-Page.
- -
4.11) Was ist ein R-Tree Index?
- -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. -
- - -
4.12) Was ist "Genetic Query Optimization"?
- -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. - - -
4.13) Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche mit Ignorierung der Groß- und Kleinschreibweisen?
- -~ und ~* sind wahrscheinlich das, was Du willst. -Vgl. psql's \do Befehl.
- - -
4.14) Wie ermittle ich in einem Query, daß ein Feld NULL ist?
- -Du testest die Spalte mit IS NULL und IS NOT NULL.
- - -
4.15) Was ist der Unterschied zwischen den verschiedenen CHAR-Typen?
- --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. -
- - -
4.16) Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Inhalts?
- -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.
- -
4.17) Was ist ein Oid? Was ist ein Tid?
- -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. - -
4.18) Was ist die Bedeutung der verschiedenen Ausdrücke, die in PostgreSQL benutzt werden (z.B. attribute, class,...)?
- -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.
+ --------------------- = 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.
-Das erfordert derart extreme Genialität, daß die Autoren es niemals versucht haben, -obwohl es im Prinzip zu machen wäre.+
+
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.
- - + + -- cgit v1.2.3