Deutsche �bersetzung von Ian Barwick (barwick@gmx.net).
!Letzte Aktualisierung der deutschen �bersetzung: So., den 15.12.2002, 18: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.
Deutsche �bersetzung von Ian Barwick (barwick@gmx.net).
!Letzte Aktualisierung der deutschen �bersetzung: Fr., den 14.02.2003, 22:30 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.ca.PostgreSQL.org/users-lounge/docs/faq.html eingesehen werden.
Eine eigenst�ndige Portierung auf MS Win NT/2000/XP befindet sich in Vorbereitung.
--- 213,219 ---- (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.ca.PostgreSQL.org/docs/faq-mswin.html.Eine eigenst�ndige Portierung auf MS Win NT/2000/XP befindet sich in Vorbereitung.
*************** *** 270,281 ****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.3.
Wir planen alle 4 Monate eine neue Version herauszugeben.
--- 270,281 ----Eine Liste von Unternehmen, die Support f�r PostgreSQL auf kommerzieller Basis leisten, kann unter ! http://www.ca.PostgreSQL.org/users-lounge/commercial-support.html eingesehen werden.
Die neueste Version von PostgreSQL ist 7.3.2 .
Wir planen alle 4 Monate eine neue Version herauszugeben.
*************** *** 665,675 **** erlaubter Backend-Prozesse wird verhindert, dass System-Ressourcen durch PostgreSQL aufgebraucht werden. -In den PostgreSQL-Versionen vor 6.5 war die maximale Anzahl von Backends - auf 64 festgelegt und eine �nderung setzte eine erneute Kompilierung - voraus, bei der die Konstante MaxBackendId in include/storage/sinvaladt.h - entsprechend angepasst werden mu�te. -
Dieses Verzeichnis enth�lt tempor�re Dateien, die durch den query executor --- 665,670 ---- *************** *** 861,866 **** --- 856,865 ----
(Die Aggregatfunktionen MIN() und MAX() verwenden keine Indizes).
+Sollte es danach aussehen, also ob der Optimierer irrt�mlich einen sequentiellen + Scan ausf�hrt, f�hren Sie SET enable_seqscan TO 'off' aus und pr�fen + Sie, ob die Indexabfrage dadurch scheller geworden ist.
+Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, k�nnen Indizes nur unter bestimmten Umst�nden verwendet werden:
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.
Typ interner Name Bemerkungen
-------------------------------------------------
VARCHAR(n) varchar die Gr��e legt die Maximall�nge fest; kein
Ausf�llen mit Leerzeichen
+ CHAR(n) bpchar mit Leerzeichen gef�llt bis zur angegebenen L�nge
TEXT text Die L�nge wird nur durch die maximale Zeilenl�nge
beschr�nkt
BYTEA bytea Bytearray mit variabler L�nge
+ "char" char 1 Zeichen
Der interne Name kommt vor allem in den Systemkatalogen und in manchen Fehlermeldungen vor.
!Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes geben die L�nge an, gefolgt von den Daten). Daher ist der tats�chlich belegte Platz immer etwas mehr als die deklarierte Feldgr��e. Allerdings wird unter Umst�nden auf diese Datentypen Datenkompression durch das TOAST- Verfahren angewendet, womit der tats�chlich belegte Platz auch geringer als erwartet ausfallen kann.
+ +F�r die Speicherung von Zeichenketten variabler L�nge empfiehlt sich VARCHAR(n). + Die maximale L�nge eines VARCHAR(n)-Felds wird bei der Tabellendefinition + festgelegt. TEXT setzt keine L�ngengrenze, allerdings gibt es + eine systembedingte Obergrenze von 1 GB. + +
CHAR(n) ist geeignet f�r die Speicherung von Zeichenketten, die alle + die gleiche L�nge haben. Bitte beachten Sie, dass CHAR(n) automatisch Zeichenketten + bis zur definierten Feldl�nge mit Leerzeichen ausf�llt, w�hrend bei VARCHAR(n) nur + die tats�chlich eingegebene Zeichenkette gespeichert wird.
!BYTEA ist f�r bin�re Daten, besonders f�r Werte, die NULL-Bytes haben.
!Die hier erw�hnten Typen weisen �hnliche Performanzeigenschaften auf.
OIDs sind PostgreSQLs Antwort auf eindeutige Zeilen-IDs. Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID. Alle --- 1048,1054 ---- 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 *************** *** 1156,1162 ****
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.
Damit diese Abfrage effizient durchgef�hrt wird, sollte f�r 'spalte2' ein Index angelegt worden sein. Die Einschr�nkung von Abfragen mit IN ! wird in der n�chsten PostgreSQL-Version (7.4) behoben werden.