FAQ/de

From PostgreSQL wiki
< FAQ(Redirected from Häufig gestellte Fragen)
Jump to navigationJump to search


Allgemeine Fragen

Was ist PostgreSQL? Wie wird es ausgesprochen?

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt. (Für diejenigen, die es interessiert: eine MP3-Datei mit der amerikanischen Aussprache befindet sich hier: http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen kombiniert. PostgreSQL ist freie Software und dessen kompletter Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung von PostgreSQL verantwortlich. Es handelt sich um ein Gemeinschaftsprojekt, das nicht von einer bestimmten Firma kontrolliert wird. Lesen Sie die Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer Mitarbeit interessiert sind.

Wer kontrolliert PostgreSQL?

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas existiert gar nicht. Es gibt zwar das "Core Committee" sowie Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die Community gesteuert, die aus den Entwicklern sowie natürlich auch den Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

Welchem Copyright unterliegt PostgreSQL?

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem muß der Copyright- Text in allen Kopien der Software enthalten sein. Dies ist der Originaltext der BSD-Lizenz: 

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, 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.

Es gilt die Copyright-Klausel im Original!

Auf welchen Plattformen läuft PostgreSQL?

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen Plattform eingesetzt werden. Diejenigen Plattformen, die bei der jeweiligen Versionsfreigabe getestet wurden, sind in den Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes Installationspaket kann von http://pgfoundry.org/projects/pginstaller heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98, WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

Woher bekomme ich PostgreSQL?

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier: ftp://ftp.postgresql.org/pub/.

Was ist die neueste Version von PostgreSQL?

Die neueste Version von PostgreSQL kann auf der Website eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.

Wo bekomme ich Support für PostgreSQL?

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die Web-Seite http://www.postgresql.org/community/lists/ bietet einen Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier: http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Libera (irc.libera.chat). Unter UNIX/Linux können Sie mit z.B. irc -c '#postgresql' "$USER" irc.libera.chat. daran teilnehmen. Auf Libera gibt es folgende Channels:

  • #postgresql-es (spanisch)
  • #postgresqlfr (französischen)
  • #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

Wie kann ich einen Fehlerbericht abgeben?

Nutzen Sie das Formular unter http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen bekanntgegeben wurden, erhalten typischerweise einer der folgenden Reaktionen:

  • es ist kein Bug, der Grund wird benannt
  • es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
  • der Bug wurde in der aktuellen Version behoben
  • der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
  • es wird um eingehendere Informationen gebeten, z.B.:
    • Betriebssystem
    • PostgreSQL-Version
    • reproduzierbares Fallbeispiel
    • Debugging-Information
    • Debugger-Backtrace-Ausgabe
  • der Bug ist neu. Folgendes könnte passieren:
    • ein Patch wird erstellt und in der nächsten Version eingebaut
    • der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

Wie erfahre ich von bekannten Bugs oder fehlenden Features?

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html für eine Auflistung der bekannten Bugs, fehlenden Features und zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der folgenden Antworten:

  • das Feature ist bereits auf der TODO-Liste
  • das Feature ist nicht wünschenswert, weil:
    • es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
    • es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
    • es wäre unsicher bzw. unzuverlässig
  • das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

Welche Dokumentation ist für PostgreSQL verfügbar?

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc- Verzeichnis. Ausserdem sind alle Handbücher online unter http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter http://www.postgresql.org/docs/books/awbook.html und http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter http://www.postgresql.org/docs/books Diverse technische Artikel befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen, Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

Wie kann ich SQL lernen?

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten Einstieg. 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).

Es gibt ausserdem einige nützliche Online-Tutorials:

Wie kann ich im Entwicklerteam mitarbeiten?

Lesen Sie in der Entwickler-FAQ unter Developer FAQ nach.

Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen?

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften, Performanz, Zuverlässigkeit, Support und Preis.

Eigenschaften

      PostgreSQL besitzt die meisten Eigenschaften - wie
      Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
      referenzielle Integrität bei Fremdschlüsseln und verfeinertes
      Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
      bietet außerdem einige anderen Eigenschaften, die diese nicht
      immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
      und die Multi-Versionen-Steuerung zum Verringern
      konkurrierender Locks.

Performanz

      Die Performanz von PostgreSQL ist mit der von kommerziellen und
      anderen Open-Source-Datenbanken vergleichbar. In manchen
      Bereichen ist es schneller, in anderen langsamer. In der Regel
      beträgt der Unterschied +/-10%.

Zuverlässigkeit

      Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
      zuverlässig arbeitet. Daher bemühen wir uns, nur streng
      geprüften und beständigen Code freizugeben, der nur ein Minimum
      an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
      Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
      beweist, dass wir stabile und solide Versionen freigeben, die
      im Produktionsbetrieb genutzt werden können. Wir glauben, dass
      wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
      dastehen.

Support

      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 und
      der Zugriff auf die Handbücher und den Quellcode ermöglicht
      einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
      gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
      (siehe FAQ-Punkt 1.7).

Preis

      PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
      auch 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.

Kann PostgreSQL eingebettet (embedded) werden?

PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme?

Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen. PostgreSQLs Majordomo erreichen Sie hier.

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für eliminatecc. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für selfcopy. PostgreSQLs Majordomo erreichen Sie hier.

Fragen zu Benutzerprogrammen

Welche Schnittstellen gibt es für PostgreSQL?

Die PostgreSQL-Installation stellt nur Schnittstellen für C und Embedded C bereit. Alle weitere Schnittstellen sind unabhängige Projekte, die einzeln heruntergeladen werden werden müssen. Diese Trennung ermöglicht individuelle Entwickler-Teams und Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL- Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl, TCL, Python und viele anderen sind unter http://gborg.postgresql.org im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

Wie kann man PostgreSQL in einer Website nutzen?

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm oder mod_perl auch an.

Hat PostgreSQL eine grafische Benutzerschnittstelle?

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl kommerziell als auch Open-Source. Eine englische Liste befindet sich hier.

Administrative Fragen

Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql?

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

Wie regle ich Zugriffe von anderen Rechnern?

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind. Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn Sie in der Datei postgresql.conf die Einstellung listen_addresses anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte Authentifizierung einschalten und den Server neu starten.

Wie kann ich eine bessere Performanz erreichen?

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt werden können:

Abfrageoptimierung

Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

Server-Konfiguration

Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

Hardware-Auswahl

Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

Welche Debugging-Funktionen sind für PostgreSQL verfügbar?

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests sehr nützlich sein.

Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum?

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in postgresql.conf den Wert max_connections ändern und den Server neustarten.

Wie wird PostgreSQL aktualisiert?

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf der Seite http://www.postgresql.org/support/versioning. Detaillierte technische Informationen gibt es auf der Seite http://www.postgresql.org/docs/current/static/install-upgrading.html

Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar?

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "Olzen timezone database".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

Welche Hardware eignet sich für den Betrieb mit PostgreSQL?

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich gibt es allerdings sehr große Abweichungen in der Qualität. Für einen Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI, Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

Fragen zum Betrieb

Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus?

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung mit einem Index verwendet wird, ist es möglich, dass die gesamte Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random(): 

   SELECT spalte
     FROM tabelle
 ORDER BY random()
    LIMIT 1


Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen?

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere psql-Befehle lassen sich mit \? anzeigen. 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. Außerdem biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele SELECT- Abfragen, mit deren Hilfe man Information über die Systemtabellen erhalten kann.

Wie ändere ich den Datentyp einer Spalte?

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor: 

   BEGIN;
   ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
   UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
   ALTER TABLE tabelle DROP COLUMN alte_spalte;
   COMMIT;


Um den Speicherplatz freizugeben, der von der gelöschten Spalte verwendet wurde, führen Sie VACUUM FULL aus.

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 32 TB)
Maximale Größe einer Tabelle?            32 TB
Maximale Größe einer Zeile?              400 GB
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 Indexen für eine Tabelle?
                                         unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können vervierfacht werden, indem man die Default-Blockgröße auf 32 KB heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit Text belegten Spalte suchen zu können, verwenden Sie einen Volltext-Index.

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 5,2 MB: 

24 Bytes: jeder Zeilenkopf (ungefähr)

+24 Bytes: ein Integer-Feld und ein Textfeld + 4 Bytes: Zeiger auf der Datenseite auf den Tupel 

52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB), also: 8192 Bytes pro Seite

= 146 Zeilen pro Seite (abgerundet) 

 52 Bytes pro Zeile

100.000 Datenzeilen

= 685 Datenbankseiten (aufgerundet) 

   158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig Platz in Anspruch nehmen.

Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum?

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe werden nur dann verwendet, wenn die abzufragende Tabelle eine bestimmte Größe übersteigt, und die Abfrage nur eine kleine Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der, dass die durch einen Index verursachten Festplattenzugriffe manchmal länger dauern würden 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 Indexe verwendet werden sollen. Statistiken sind auch bei der Ermittlung der optimalen JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja auch verändert.

Indexe 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.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off' aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe nur unter bestimmten Umständen verwendet werden:

  • Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
    • LIKE-Suchmuster dürfen nicht mit % anfangen;
    • ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
  • Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
  • Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
  • Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet?

Eine ausführliche Erklärung zu diesem Thema findet sich in der EXPLAIN Dokumentation.

Wie änder ich das Sortierverhalten von textähnlichen Daten?

PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen?

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren, werden in der Regel so ausgedruckt: 

  SELECT *
    FROM tabelle
   WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen funktionalen Index an, so wird er auf jeden Fall verwendet: 

  CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können keine Werte in die Spalte eingefügt werden, die sich nur durch ihre Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß ein CHECK-Constraint oder ein Trigger eingesetzt werden.

Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden?

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL. 

  SELECT 
     *
  FROM 
     tabelle
  WHERE 
     spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten COALESCE() 

  SELECT 
     COALESCE(col1, ) || COALESCE(col2, )
  FROM tab;


Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden: 

  SELECT 
     *
  FROM 
     tabelle
  ORDER BY 
     (spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende) 

  SELECT 
     *
  FROM 
     tab
  ORDER BY 
     col NULLS FIRST;

Was ist der Unterschied zwischen den verschiedenen CHAR-Typen?

Typ interner Name Bemerkungen
VARCHAR(n) varchar die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
CHAR(n) bpchar mit Leerzeichen gefüllt bis zur angegebenen Länge
TEXT text keine obere Grenze für die Länge
BYTEA bytea Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
"char" (with the quotes) char ein Zeichen

Der interne Name kommt vor allem in den Systemkatalogen und in manchen Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich belegte Platz immer etwas mehr als die deklarierte Feldgröße. Allerdings wird unter Umständen auf diese Datentypen Datenkompression durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der Tabellendefinition festgelegt. TEXT setzt keine Längengrenze, allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt, während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften auf.

Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert?

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

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
  );

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen: tabellederspalte-namederspalte_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

Wie bekomme ich den Wert einer SERIAL-Sequenz?

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.11.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')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus: INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

Führt currval() zu einer Race-Condition mit anderen Nutzern?

Nein. currval() liefert einen Wert zurück, der von Ihrer Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur Verfügung steht.

Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte?

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern, werden Sequenzen gerade nicht für andere Transaktionen gesperrt, sondern die Sequenznummern werden den laufenden Transaktionen sofort zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene Transaktionen verursacht.

Was ist ein OID?

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

Was ist ein CTID?

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"?

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.

Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft?

Geben Sie in psql SELECT VERSION(); ein.

Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll?

Dazu verwenden Sie CURRENT_TIMESTAMP: 

  CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

Wie führe ich eine OUTER JOIN durch?

PostgreSQL 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 RIGHT JOIN würde hingegen alle unverknüpften Zeilen in tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale Verknüpfungen sind INNER JOINs.

Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen?

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende Abfragen über Funktionsaufrufe ermöglicht.

Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen?

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.: http://www.postgresql.org/docs/techdocs.17.

Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze?

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen 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 gecachten Funktionsinhalte noch auf die alte temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin, in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht mehr auf.

Welche Replikationslösungen gibt es?

Der Begriff "replikation" umfasst mehrere verschiedene Technologien, jede mit eigenen Vor- und Nachteilen. Die Dokumentation enthält eine gute Einführung in das Thema Replikation

Mit "Master/slave"-Replikation werden Änderungen in einer Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings hat diese Art von Replikation eine negative Auswirkung auf die Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu synchronisieren. Pgcluster ist die populärste freie Lösung für PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte Replikationslösungen für verschiedene Arten der Replikation.

Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt?

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der Anlegung von Tabellen, z.B.: 

   CREATE TABLE "Tabelle"
               ("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle" verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der folgenden Punkte beachten:

  • bei der Tabellenanlegung keine Gänsefüßchen verwenden;
  • in Identifikatoren nur Kleinschreibung verwenden;
  • immer Identifikatoren mit Gänsefüßchen versehen

Anmerkungen des Übersetzers

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer unter http://sql-info.de/postgresql/FAQ_german.html. Diese "Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

Retrieved from "https://wiki.postgresql.org/index.php?title=FAQ/de&oldid=36308"