Ostatnia aktualizacja: Sobota Luty 7 22:16:21 EST 2004
Ostatnia aktualizacja t�umaczenia: Pi�tek Marzec 5 19:31:12 EST 2004
Obecny maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
T�umaczenie: Marcin Mazurek (m.mazurek@netsync.pl)
Najbardziej aktualn� wersj� tego dokumentu mo�na znale�� pod adresem: http://www.PostgreSQL.org/docs/faqs/FAQ.html.
Odpowiedzi na pytania dotycz�ce konkretnych system�w operacyjnych mo�na znale�� pod adresem: http://www.PostgreSQL.org/docs/index.html.
IN s� takie wolne?PostgreSQL wymawia si� Post-Gres-kju-el. Cz�sto podczas rozm�w u�ywany jest termin "Postgres"
PostgreSQL jest rozszerzeniem systemu zarz�dzania bazami danych - POSTGRES, kolejn� generacj� rozwojowego prototypu DBMS. Mimo, �e PostgreSQL zachowa� bardzo dobrze zbudowany model danych (data model) i bogaty zestaw typ�w danych POSTGRES'a, zast�pi� PostQuel'owy j�zyk zapyta� z rozbudowanym podzbiorem j�zyka SQL. PostgreSQL jest oprogramowaniem darmowym z dost�pnymi ca�ymi �r�d�ami.
Rozw�j PostgreSQL jest prowadzony przez grup� ludzi z Internetu, komunikuj�cych si� poprzez mailowe listy dyskusyjne PostgreSQL. Obecnym koordynatorem jest Marc G. Fournier (scrappy@PostgreSQL.org). (Zobacz pytanie 1.6 jak si� przy��czy�). Ta grupa ludzi jest odpowiedzialna za ca�y rozw�j PostgreSQL. PostgreSQL jest projektem nie kontrolowanym przez �adn� firm�, aby wzi�� udzia� w jego rozwoju sprawd�, http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html
Autorami PostgreSQL 1.01 byli Andrew Yu and Jolly Chen. Wiele innych os�b pomog�o przy portowaniu, testowaniu, debugowaniu i rozwijaniu kodu. Oryginalny kod Postgresa, na kt�rym zosta� oparty PostgreSQL, by� wysi�kiem student�w oraz pracownik�w pracuj�cych pod kierownictwem profesora Michael'a Stonebraker'a z University of California w Berkeley.
Oryginaln� nazw� oprogramowania w Berkeley by� Postgres. Po dodaniu obs�ugi SQL w 1995, nazwa zosta�a zmieniona na Postgres95. Pod koniec roku 1996 nazwa zosta�a zmieniona na PostgreSQL.
PostgreSQL obj�ty jest nast�puj�c� licencj�:
PostgreSQL Data Base Management System
Portions Copyright (c) 1996-2005, 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.
Tekst powy�ej, jest klasyczn� licencj� BSD. Nie posiada ona �adnych restrykcji co do u�ywania kodu �r�d�owego. Podoba nam si� i nie zamierzamy jej zmienia�.
PostgreSQL powinien dzia�a� na wszystkich nowych Unix-podobnych systemach. Platformy, kt�re zosta�y szczeg�owo przetestowane podczas publikowania PostgreSQL s� wymienione w dokumentacji opisuj�cej instalacj�.
Klient
Mo�liwa jest kompilacja bibliteki C libpq, psql oraz innych interfejs�w i uruchamianie ich na platformie MS Windows. W tym wypadku klient jest uruchamiany na MS Windows a z serwerem komunikuje si� poprzez TCP/IP. Serwer mo�e dzia�a� na dowolnej wspieranej platformie Unixowej. Plik win32.mak jest do��czony do �r�de�, aby mo�na by�o stworzy� bibliotek� libpq oraz program psql dzia�aj�ce w �rodowisku Win32. PostgreSQL mo�e si� tak�e komunikowa� z klientami ODBC.
Serwer
Serwer mo�e by� uruchamiany na Windows NT i Win2k u�ywaj�c bibliotek Cygwin, Cygnus Unix/NT. W pliku pgsql/doc/FAQ_MSWIN znajduj�cym si� w �r�d�ach lub pod adresem: http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN na naszych stronach.
Obecnie prowadzone s� prace nad stworzeniem wersji dla MS Win NT/200/XP. Je�li chcesz si� dowiedzie� o obecnym statusie tych prac zobacz http://techdocs.postgresql.org/guides/Windows and http://momjian.postgresql.org/main/writings/pgsql/win32.html.
Istnieje tak�e port pod Novell Netware 6 dost�pny pod adresem http://forge.novell.com.
G��wny serwer ftp z dost�pem "anonymous" dla PostgreSQL znajduje si� ftp://ftp.PostgreSQL.org/pub. je�li szukasz mirror�w sprawd� nasz� g��wn� stron� www.
Adres g��wnej listy mailowej: pgsql-general@PostgreSQL.org. Jest ona przeznaczona dyskusjom dotycz�cym spraw zwi�zanych z PostgreSQL. �eby zapisac si� na list�, wy�lij email z nast�puj�cymi liniami w tre�ci maila (nie w temacie):
subscribe
end
na adres: pgsql-general-request@PostgreSQL.org.
Dost�pna jest tak�e lista wysy�aj�ca digesty. Aby zapisa� si� na ni�, wy�lij email na adres: pgsql-general-digest-request@PostgreSQL.org z tre�ci� maila zawieraj�c�:
subscribe
end
Digesty s� wysy�ane do cz�onk�w listy, kiedy na g��wn� list� dotrze ok
30k wiadomo�ci.
Dost�pna jest tak�e lista po�wi�cona b��dom znalezionym w PostgreSQL. Aby zapisa� si� na ni� wy�lij email na adres: pgsql-bugs-request@PostgreSQL.org z tre�ci� maila zawieraj�c�:
subscribe
end
Lista po�wi�cona dyskusjom developer�w jest dost�pna pod adresem:
pgsql-hackers-request@PostgreSQL.org
Aby si� na ni� zapisa� wy�lij na jej adres mail z tre�ci�:
subscribe
end
Dodatkowe informacje o listach mailowych dotycz�cych PostgreSQL mo�na znale�� na stronach WWW PostgreSQL pod adresem:
http://www.PostgreSQL.org
W sieci EFNet istnieje kana� IRC #PostgreSQL. Ja, do
po��czenia si� z kana�em u�ywam Unixowego polecenia irc -c
'#PostgreSQL' "$USER" irc.phoenix.net.
Lista firm oferuj�cych wsparcie na zasadach komercyjnych znajduje si� pod adresem: http://techdocs.postgresql.org/companies.php.
Ostatnia dost�pna wersja PostgreSQL to 7.4.1.
Planujemy publikowanie kolejnych wersji co sze�� do o�miu miesi�cy.
Kilka manuali, stron pod�cznika man, oraz kilka przyk�ad�w do testowania s� za��czone w samej dystrybucji. Znajduj� si� one w katalogu /doc. Manual mo�e by� tak�e przegl�dany poprzez strony www pod adresem http://www.PostgreSQL.org/docs.
Istniej� tak�e dwie ksi��ki dost�pne online pod adresami http://www.PostgreSQL.org/docs/awbook.html i http://www.commandprompt.com/ppbook/. Lista ksi��ek o PostgreSQL, kt�re mo�na kupi� znajduje si� pod adresem http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Zbi�r technicznych artyku��w o PostgreSQL znajduje si� pod adresem http://techdocs.postgresql.org/.
psql posiada kilka wbudowanych polece� \d, za pomoca kt�rych mo�na sprawdzi� informacje dotycz�ce typ�w, operator�w, funkcji, agregat�w itd.
Na naszej stronie mo�na znale�� du�o wi�cej dokumentacji.
PostgreSQL wspiera rozszerzony podzbi�r standardu SQL-92. Sprawd� nasz� list� TODO aby znale�� informacj� o znanych problemach, brakuj�cych rozwi�zaniach czy przysz�ych planach.
Ksi��ka o PostgreSQL http://www.PostgreSQL.org/docs/awbook.html uczy SQL. Jest jeszcze inna ksi�zka o PostgreSQL dost�pna pod adresem: http://www.commandprompt.com/ppbook. Dobry tutorial mo�esz znale�� pod adresem: http://www.intermedia.net/support/sql/sqltut.shtm, oraz http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, i http://sqlcourse.com.
Jeszcze inny to "Teach Yourself SQL in 21 Days, Second Edition" pod adresem: http://members.tripod.com/er4ebus/sql/index.htm
Wielu z naszych u�ytkownik�w poleca The Practical SQL Handbook, Bowman, Judith S., et al., Addison-Wesley. Inni polecaj� The Complete Reference SQL, Groff et al., McGraw-Hill.
Tak, bez problemu radzimy sobie z datami po roku 2000 AD, oraz przed rokiem 2000 BC.
Przede wszystkim �ci�gnij ostatnie dost�pne �r�d�a i przeczytaj dokumentacj� przeznaczon� dla developer�w na naszej stronie www lub dost�pn� tak�e w �r�d�ach PostgreSQL. Nast�pnie zapisz si� na listy mailowe pgsql-hackers i pgsql-patches. I na koniec, wysy�aj nam wysokiej jako�ci patch'e na list� pgsql-patches.
Jest oko�o 12 os�b, kt�re maj� uprawnienia do commit'owania w CVS PostgreSQL'a. Ka�dy z nich submitowa� tak wiele wysokiej jako�ci patchy, �e sta�o si� niemo�liwe dla obecnych commiter�w by� z nimi na bie��co, wi�c musieli�my im ufa� i mie� pewno��, �e ich poprawki s� wysokiej jako�ci.
Zajrzyj na stron� PostgreSQL BugTool, na kt�rej opisane s� wskaz�wki jak zg�asza� informacje o b��dach.
Zajrzyj tak�e na nasz ftp ftp://ftp.PostgreSQL.org/pub, aby sprawdzi� czy nie ma nowszych wersji PostgreSQL czy patchy.
Jest kilka sposob�w oceny softwaru: mo�liwo�ci, wydajno��, stabilno��, wsparcie i cena.
PostgreSQL korzysta z najlepszej infrastruktury od samego pocz�tku istnienia projektu, czyli roku 1996 kiedy rozpoczeli�my prac�. Wszystko to zawdzi�czamy Marc'owi Fournier'owi, kt�ry stworzy� t� infrastruktur� i zarz�dza ni� od lat.
Wysokiej jako�ci infrastruktura jest bardzo wa�na dla ka�dego projektu open-source. Zapobiega przerwom w rozwoju projektu i jakimkolwiek przestojom.
Oczywi�cie korzystanie z wysokiej jako�ci infrastruktury nie jest tanie. Istnieje wiele r�nych miesi�cznych, czy jednorazowych wydatk�w, kt�re trzeba ponosi� aby wszystko dzia�a�o jak nale�y. Je�li Ty, b�d� Twoja firma mo�e wspom�c finansowo rozw�j PostgreSQL odwied� adres: http://store.pgsql.com/shopping/ gdzie opisane jest jak to zrobi�.
Chocia� na stronie wspomniana jest nazwa PostgreSQL Inc, "datki" s� przeznaczone jedynie na rozw�j projektu PostgreSQL i nie s� przeznaczane na finansowanie jakiejkolwiek firmy. Je�li wolisz, mo�esz wys�a� czek na adres kontaktowy.
Dost�pne s� dwa driwery ODBC: PsqlODBC i OpenLink ODBC.
Mo�esz pobra� PsqlODBC z adresu http://gborg.postgresql.org/project/psqlodbc/projdisplay.php
OpenLink ODBC mo�e by� pobrany z adresu: http://www.openlinksw.com. Wsp�pracuje ze standardowym oprogramowaniem klienckim ODBC wi�c w ten spos�b mo�esz korzysta� z PostgreSQL ODBC dost�pnego na ka�dej pltaformie kt�r� wspiera (Win, Mac, Unix, VMS).
Autorzy b�d� prawdopodobnie sprzedawa� ten produkt osobom kt�re wymagaj� komercyjnego wsparcia, ale wersja darmowa b�dzie zawsze dost�pna. Wszystkie pytania mo�esz wysy�a� na adres: postgres95@openlink.co.uk.
Dobry podr�cznik dla pocz�tkuj�cych o dost�pie do bazy danych przez www mo�esz znale�� pod adresem: http://www.webreview.com
Do integracji z www, �wietnym rozwi�zaniem jest PHP. Mo�esz znale�� wi�cej informacji na ten temat pod adresem http://www.php.net.
Wiele os�b w przypadku skomplikowanych rozwi�za� uzywa Perl'a i modu�u CGI.pl lub mod_perl.
Tak, istnieje kilka interfejs�w graficznych dla PostgreSQL. W�r�d nich PgAccess ( http://www.pgaccess.org), PgAdmin III (http://www.pgadmin.org), RHDB Admin (http://sources.redhat.com/rhdb/ ) oraz Rekall ( http://www.thekompany.com/products/rekall/, komercyjny). Istnieje tak�e PHPPgAdmin ( http://phppgadmin.sourceforge.net/ ), webowy interfejs dla PostgreSQL.
Wi�cej informacji na ten temat znajduje si� pod adresem See http://techdocs.postgresql.org/guides/GUITools.
Najbardziej popularne j�zyki posiiadaj� w�asny interfejs dla PostgreSQL. Sprawd� list� rozszerze� dla intersuj�cego Ciebie j�zyka programowania.
Ze �r�d�ami PostreSQL dystrubuowane s� interfejsy dla nast�puj�cych j�zyk�w programowania:
U�yj opcji --prefix podczas uruchamiania skryptu configure.
Ten b��d mo�e by� wynikiem wielu problem�w, ale na pocz�tek sprawd� czy masz zainstalowane rozszerzenia systemu V w j�drze systemu. PostgreSQL wymaga do pracy zainstalowanej obs�ugi pami�ci dzielonej i semafor�w.
Albo nie masz poprawnie skonfigurowanej obs�ugi pami�ci dzielonej w j�drze systemu, albo musisz zwi�kszy� jej dost�pny rozmiar. Dok�adna ilo�� jak� potrzebujesz jest zale�na od architektury systemu na jakim pracujesz, jak du�o bufor�w oraz jak du�o proces�w backendu skonfigurowa�e� dla postmaster'a. Dla wi�kszo�ci system�w, z domy�ln� liczb� bufor�w i proces�w potrzebujesz minimum w przybli�eniu 1MB. Zobacz PostgreSQL Administrator's Guide gdzie szczeg�owo zosta�o opisane wykorzystanie pami�ci dzielonej i semafor�w.
Je�li tre�� b��du brzmi: IpcSemaphoreCreate: semget failed (No space left on device) oznacza to, �e j�dro systemu nie jest skonfigurowane do obs�ugi wystarczaj�cej liczby semafor�w. Postgres wymaga jednego semafor'a na potencjalny jeden proces backend. Tymczasowym rozwi�zaniem jest uruchomienie programu postmaster z mniejsz� maksymaln� liczb� proces�w backend. U�yj opcji -N z parameterem mniejszym od domy�lnego - 32. Bardziej trwa�ym rozwi�zaniem jest zwi�kszenie parametr�w SEMMNS i SEMMNI j�dra twojego systemu.
Niedzia�aj�ce semafory mog� spowodowa� niepoprawne zamkni�cie systemu w czasie intensywnego korzystania z bazy.
Je�li tre�� b��du jest inna, mo�e to oznacza�, �e obs�uga semafor�w nie zosta�a w��czona do j�dra wcale. Zobacz PostgreSQL Administrator's Guide po bardziej szczeg�owe informacje o pami�ci dzielonej i semaforach.
Domy�lnie PostgreSQL pozwala jedynie na po��czenia za pomoc� socket�w Unixowych z lokalnego hosta. Inne hosty nie b�d� mog�y si� po��czy� z serwerem dop�ki nie zostanie dodana opcja -i do postmaster'a, oraz nie umo�liwi si� autoryzacji na podstawie adresu host�w modyfikuj�c odpowiednio plik $PGDATA/pg_hba.conf. To zmiany pozwol� na po��czenia TCP/IP.
Indeksy bez w�tpienia mog� przyspieszy� wykonywanie zapyta�. Polecenie EXPLAIN pozwala zobaczy� jak PostgreSQL interpretuje Twoje zapytanie i kt�re indeksy s� u�ywane.
Je�li wykonujesz bardzo du�o INSERT�w, mo�e warto je wykona� za pomoc� jednego du�ego pliku u�ywaj�c polecenia COPY. Jest to du�o szybsze ni� pojedyncze INSERTy. Po drugie polecenia SQL nie zawarte w bloku okre�laj�cym transakcj� - BEGIN WORK/COMMIT, s� traktowane jako pojedyncza transakcja. Rozwa� wykonanie kilku polece�/zda� SQL w jednym bloku transakcji. To redukuje narzut nak�adany przez transakcj�. Przy du�ych zmianach w danych, warto usun�� i stworzy� na nowo indeksy.
Jest kilka opcji pozwalaj�cych na poprawienie wydajno�ci. Mo�esz wy��czy� fsync() poprzez uruchomienie postmaster'a z opcjami -o -F. To spowoduje, �e fsync() nie b�dzie zrzuca� danych na dysk po ka�dej transakcji.
Mo�esz tak�e uruchomi� postmaster'a z opcj� -B aby zwi�kszy� wielko�� pami�ci dzielonej u�ywanej przez procesy backend�w. Je�li ustawisz t� warto�� zbyt wysoko i przekroczysz limity ustawione przez kernel na pami�� dzielon�, postmaster mo�e si� nie uruchomi�. Ka�dy bufor zajmuje 8K a domy�lna ilo�� bufor�w to 64.
Mo�esz tak�e u�y� opcji -S dla backendu aby zwi�kszy� maksymaln� warto�� pami�ci u�ywan� przez proces backendu podczas sortowania. Opcja -S jest ustawiana warto�ci� podawan� w kilobajtach, domy�lna warto�� to 512K.
Mo�esz tak�e u�y� polecenia CLUSTER aby pogrupowa� dane w tabelach wg indeksu. Zobacz opis polecenia CLUSTER w manualu �eby dowiedzie� si� wi�cej.
PostgreSQL ma kilka mo�liwo�ci na raportowanie informacji o jego statusie, kt�re mog� by� przydatne przy debugowaniu procesu.
Przede wszystkim uruchom skrypt configure z opcj� --enable-cassert, wiele funkcji assert() monitoruj� post�p procesu backend i zatrzymuj� program kiedy wydarzy si� co� nieoczekiwanego.
Zar�wno postmaster jak i postgres maj� kilka opcji do debugowania. Za ka�dym razem kiedy uruchamiasz postmaster'a, upewnij si�, �e wysy�asz standardowe wyj�cie i error do pliku z logami, np. w ten spos�b:
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
To utworzy plik server.log w g��wnym katalogu PostgreSQL. Ten plik zawiera po�yteczne informacje o problemach i b��dach, kt�re wydarzy�y si� podczas pracy serwera. Postmaster posiada opcj� -d, kt�ra pozwala na raportowanie bardzo szczeg�lowych informacji. Do opcji -d podajemy liczb�, kt�ra okre�la szczeg�owo�� wysy�anych informacji. Musisz mie� �wiadomo��, �e wysoki poziom logowania b�dzie powodowa� tworzenie bardzo duzych plik�w z logami.
Je�li postmaster nie zosta� uruchomiony, mo�esz uruchomi� postgres'owy backend z linii polece�, i uruchomi� Twoje polecenie SQL bezpo�rednio na nim. Taki spos�b jest polecany jedynie w przypadku debugowania. Zwr�� uwag�, �e w tym wypadku zapytanie ko�czy znak nowej linii a nie �rednik. Je�li skompilowa�e� z opcjami debugowania mozesz u�y� debuggera aby sprawdzi� co si� dzieje. Poniew� backend nie zosta� uruchomiony przez postmaster'a, nie dzia�a w identycznym �rodowisku, co oznacza �e powt�rzenie warunk�w w jakich wyst�pi�y problemy moze by� problemem.
Je�li postmaster dzia�a, uruchom psql w jednym z okien, nast�pnie znajd� PID procesu postgres u�ywanego przez psql. U�yj debuggera aby do PID'u postgres'a. Mo�esz ustawia� pu�apki (breakpoints) w debuggerze i wykonywa� zapytania z psql. Je�li debugujesz uruchamianie postgres'a, mo�esz ustawi� zmienn� PGOPTIONS="-W n", nast�pnie uruchomi� psql. Opcja ta pozwoli spowolni� uruchomienie na n sekund aby� m�g� si� po��czy� z procesem za pomoc� debugera, ustawi� jakiekolwiek pu�apki i kontynuowa� proces uruchamiania.
postgres mo�e by� uruchamiany z opcjami -s, -A i -t, kt�re mog� by� bardzo przydatne przy debuggowaniu i ocenie wydajno�ci.
Mo�esz tak�e skompilowa� z profilingiem aby zobaczy� jakie funkcje ile czasu wykonuj� si�. Pliki profilowane dla backendu zostan� umieszczone w katalogu pgsql/data/base/dbname. Pliki profilu klienta zostan� umieszczone w bie��cym katalogu klienta. Linux wymaga aby kompilowa� z opcj� -DLINUX_PROFILE aby profilowanie odbywa�o si� poprawnie.
Musisz zwi�kszy� limit ilo�ci jednoczesnych proces�w bacekendu dla procesu postmaster'a.
Domy�lny limit to 32 procesy. Mo�esz go zwi�kszy� przez restart postmaster z odpowiedni� warto�ci� ustawian� opcj� -N w pliku postgresql.conf.
We� pod uwag�, �e je�li zwi�kszysz warto�� podan� w opcji -N na wi�cej ni� 32 musisz tak�e zwi�kszy� warto�� w opcji -B ponad jej domy�ln� warto�� 64; warto�� -B musi by� co najmniej dwa razy wi�ksza od warto�ci podanej w opcji -N, a prawdopodobnie powinna by� w rzeczywisto�ci jeszcze wi�ksza dla optymalnej wydajno�ci. Dla du�ej liczby proces�w backendu na pewno zauwa�ysz, �e trzeba zwi�kszy� r�ne parametry j�dra Unixa. Rzeczy, kt�re powniene� sprawdzi� to maksymalna liczba blok�w pami�ci dzielonej, SHMMAX; maksymalna liczba semafor�w, SEMMNS oraz SEMMNI; maksymalna liczba proces�w, NPROC; maksymalna liczba proces�w na jednego u�ytkownika, MAXUPRC; i maksymalna liczba otwartych plik�w, NFILE oraz NINODE. Pow�d dla kt�rego PostgreSQL ma limit na maksymaln� liczb� proces�w backendu to obawa o wyczerpanie zasob�w systemu.
Katalog ten zawiera tymczasowe pliki utworzone przez executor. Dla przyk�adu, je�li jaka� operacja sortowania jest wymagana do wykonania ORDER BY, a samo sortowanie wymaga wi�cej miejsca ni� parametr backendu -S ustawi� do wykorzystania, wtedy tymczasowe pliki s� u�ywane do przechowywania tych danych.
Pliki tymczasowe powinny by� usuni�te automatycznie, ale mog�o si� to nie sta� je�li proces backendu w mi�dzyczasie nie zako�czy� si� poprawnie podczas operacji sortowania. Je�li w danym momencie nie dzia�aj� �adne procesy backend�w mozesz spokojnie usun�� pliki pg_tempNNN.NN.
Tw�rcy PostgreSQL dokonuj� jedynie ma�ych zmian pomi�dzy ma�ymi upgradami wersji, np z 7.2 do 7.2.1, wtedy upgrade nie wymaga korzystania z dump i restore. Przy wi�kszych zmianach, np. z wersji 7.2 do 7.3, cz�sto zmianymaj� wp�yw na format przechowywanych danych. Zmiany te s� na tyle skomplikowane, �e nie utrzymujemy zgodo�ci z poprzednimi wersjami PostgreSQL. dump pozwala na wydostanie danych w takiej postaci, w kt�rej �atwe jest ich zaimportowanie do nowszych wersji bez k�opotu.
W wydaniach gdzie zmiany nie dotycz� formatu danych na dysku, mo�na wykorzysta� skryptu pg_upgrade, do upgradu bez u�ycia dump/restore. Dokumentacja do danego wydania zawiera informacj� czy mo�liwe jest u�ycie pg_upgrade.
Zobacz w manualu opis polecenia DECLARE.
Zobacz w manualu opis polecenia FETCH lub u�yj polecenia SELECT ... LIMIT....
Nawet je�li chesz pobra� kilka pierwszych rz�d�w z wyniku zapytania, ca�e zapytanie musi zosta� wykonane. Byc mo�e powiniene� skorzysta� z polecenia ORDER BY. Je�li istnieje indeks kt�ry odpowiada polom okre�lonym przez ORDER BY, PostgreSQL mo�e wykorzysta� jedynie kilka pierwszych rz�d�w, by� mo�e b�dzie konieczno�� wykonania zapytania do momentu a� zostan� znalezione po��dane wyniki.
Aby otrzyma� losowy rz�d, u�yj:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
Mo�esz sprawdzi� zawarto�� �r�de� psql, a konkretnie plik pgsql/src/bin/psql/describe.c. Zawiera on polecenia SQL kt�re generuja wyniki komend z backslashem. Mo�esz tak�e uruchomi� psql z opcj� -E wtedy po wykonaniu polecenia z backslashem wy�wietlane b�dzie zapytanie, kt�re w rzeczywisto�ci jest wykonywane.
DROP COLUMNT zosta�o dodane w wersji 7.3 przy poleceniu ALTER TABLE DROP COLUMN. We wcze��iejszych wersjach mo�esz zrobi� tak:
BEGIN;
LOCAL TABLE old_table;
SELECT ... -- wybierz wszystkie kolumny poza t� jedn� kt�rej chcesz si� pozby�
INTO TABLE new_table
FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
Aby zmieni� typ danych kolumny mo�esz zrobi� tak:
BEGIN; ALTER TABLE tab ADD COLUMN new_col new_data_type; UPDATE tab SET new_col = CAST(old_col AS new_data_type); ALTER TABLE tab DROP COLUMN old_col; COMMIT;
Oto wszystkie ograniczenia:
Maksymalny rozmiar dla bazdy danych? nieograniczony ( istniej�
bazy danych o wielko�ci 32 TB databases )
Maksymalny rozmiar dla tabeli? 32 TB
Maksymalny rozmiar dla rz�du? 1.6 TB
Maksymalny rozmiar pola? 1 GB
Maksymalna liczba rz�d�w w tabeli? nieograniczona
Maksymalna liczba kolumn w tabeli? 250-1600 w zale�ono�ci od typ�w kolumn
Makasymalna liczba indeks�w na tabeli? nieograniczona
Oczywi�cie "nieograniczony" nie jest prawd� tak do ko�ca, istniej�
ograniczenia wynikaj�ce z dost�pnego miejsca na dysku, pami�ci/swapa.
Kiedy wielko�ci te b�d� bardzo du�e mo�e odbi� si� to na wydajno�ci.
Maksymalny rozmiar tabeli, czyli 32 TB nie wymaga od systemu operacyjnego wsparcia dla du�ych plik�w. Du�e tabele s� przechowywane jako pliki o rozmiarze 1 GB, wi�c ograniczenia co do wielko�ci plik�w narzucone przez system plik�w nie s� istotne.
Masymalny rozmiar tabeli i maksymalna liczba kolumn mo�e by� zwi�kszona je�li zwi�kszymy domy�lny rozmiar bloku (block size) do 32k.
Baza danych PostgreSQL mo�e potrzebowa� do pi�ciu razy wi�cej miejsca na przechowywanie danych z plik�w tekstowych ni� ich obj�to��.
Jako przyk�ad mo�emy rozwa�y� plik sk�adaj�cy si� z 100,000 linii zbudowanych z liczby ca�kowitej oraz opisu tekstowego w ka�dej. Za��my, �e �rednio ka�dy �a�cuch tekstu w linii zajmuje 20 bajt�w. Ca�y plik powinien zajmowa� ok. 2.8 MB. Rozmiar pliku bazy danych w PostgreSQL zawieraj�cego te dane mozna oszacowa� na oko�o 6.4MB:
36 bajt�w: nag��wek ka�dego rz�du w przybli�eniu)
24 bajty: jedno pole int i jedno pole typu text
+ 4 bajty: wka�nik na stronie do krotki
--------------------------------------------------
64 bajty w jednym rz�dzie
Strona danych w PostgreSQL zajmuje 8192 bajt�w (8 KB), wi�c:
8192 bajt�w na stron�
--------------------- = 128 rz�d�w na jedn� strone w bazie (zaokr�glone w d�)
64 bajt�w na rz�d
100000 rz�d�w danych
----------------------- = 782 stron w bazie danych (zaokr�glone w g�r�)
128 rz�d�w na stron�
782 stron w bazie * 8192 bajt�w na stron� = 6,406,144 bajt�w (6.4 MB)
Indeksy nie powoduj� du�ego narzutu na zajmowane miejsce, ale zawieraj� pewne dane, wi�c w pewnych przypadkach moga by� ca�kiem du�e.
NULLe s� przechowywane jako mapy bitowe, wi�c u�ywaj� bardzo ma�o miejsca.
psql ma ca�kiem du�� ilo�� polece� z backslashem aby wydoby� takie informacje. Wprowad� \? aby zobaczy� ich spis. Istniej� tak�e tablice systemowe rozpoczynaj�ce si� od pg_, zawieraj�ce interesuj�ce Ciebie informacje. Wykonanie psql -l poka�e spis wszystkich baz danych.
Obejrzyj tak�e plik pgsql/src/tutorial/syscat.source. Zawiera on wiele z zapyta� typu SELECT, kt�re s� potrzebne aby wydoby� informacje z tablic systemowych.
�eby zdecydowa� czy indeks powinien byc u�ywany, PostgreSQL musi mie� statystyki dotycz�ce danej tabeli. S� one gromadzone przez u�ycie polecenia VACUUM ANALYZE, lub poprostu ANALYZE. u�ywaj�c statystyk, optymalizator wie ile rz�d�w jest w tabeli i mo�e lepiej okre�li� czy indeksy powinny by� u�yte. Statystyki mog� by� tak�e pomocne w okre�leniu najlepszej kolejno�ci wykonania z��czenia (join) i jego sposobu. Gromadzenie statystyk powinno si� odbywa� w okre�lonych interwa�ach czasu poniewa� dane w tabelach zmieniaj� si�.
Indeksy nie s� zazwyczaj u�ywane przez ORDER BY lub przy wykonywaniu z��cze� (join). Sekwencyjne przeszukiwanie po kt�rym nast�puje sortowanie jest zazwyczaj szybsze ni� wyszukiwanie za pomoc� indeksu na du�ej tabeli.
Jakkolwiek LIMIT w po��czeniu z ORDER BY cz�sto b�dzie wykorzystywa� indeksy poniewa� jedynie ma�a cz�� z tabeli jest zwracana. W rzeczywisto�ci, chocia� MAX() i MIN() nie u�ywaj� indeks�w, mo�liwe jest aby zwr�ci� te warto�ci u�ywaj�c indeks�w poprzez u�ycie ORDER BY i LIMIT.
SELECT col
FROM tab
ORDER BY col [ DESC ]
LIMIT 1;
Je�li uwa�asz, �e optimizer myli si� wybieraj�c sequential scan, u�yj SET enable_seqscan TO 'off' i uruchom testy aby sprawdzi� czy wtym wypadku zapytanie b�dzie szybciej wykonywane.
Kiedy u�ywa si� operator�w dopasuj�cych takich jak LIKE lub ~, indeksy b�d� u�ywane jedynie w pewnych wypadkach:
Zobacz manual dla polecenia EXPLAIN.
Indeks R-tree jest u�ywany do indeksowania danych przestrzennych. Indeks hasuuj�cy nie nadaje si� do wyszukiwania odleg�o�ci. Natomiast indeks typu B-tree mo�e wyszukiwa� odleglo�ci jedynie w jednowymiarowych przestrzeniach. R-tree indeks radzi sobie z przestrzeniami wielo-wymiarowymi. Dla przyk�adu, je�li zostanie za�o�ony indeks typu R-tree na polu typu point, system mo�e bardziej wydajnie odpowiada� na zapytania typu "select all points within a bounding rectangle."
�r�d�owym dokumentem opisuj�cym oryginalnie projektowanie R-tree indeks�w jest:
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
Ten dokument mo�esz znale�� tak�e w pracy Stonebraker'a "Readings in Database Systems".
Wbudowane indeksy R-trees radz� sobie w wielobokami i boxes. Teoretycznie, indeksy R-tree mog� by� rozszerzone o mo�liwo�ci indeksowania w wi�cej wymiarowych przestrzeniach. W praktyce, rozbudowa indeks�w R-tree wymaga troch� pracy, a w tej chwili nie dysponujemy jak�kolwiek dokumentacj� jak to zrobi�.
Modu� GEQO ma za zadanie przyspieszenie optymalizacji zapyta� ��cz�c wiele tabel za pomoc� algorytm�w genetycznych (Genetic Algorithm (GA)). Pozwala na u�ywanie du�ych zapyta� ��cz�cych tabele (join queries) bez wykorzystywania zasobo�ernego wyszukiwania.
Operator ~ moze by� wykorzystywany do wyszukiwania za pomoc� wyra�e� regularnych, a ~* do wyszukiwania case-insensitive z wyra�eniami regularnymi. Wariant case-insensitive dla LIKE zosta� nazwany ILIKE.
Por�wnania case-insensitive s� zazwyczaj wykonywane w nast�puj�cy spos�b:
SELECT *
FROM tab
WHERE lower(col) = 'abc'
W tym wypadku standardowe indeksy nie b�d� u�ywane. Mo�esz utworzy�
indeks funkcyjny, poprzez:
CREATE INDEX tabindex on tab (lower(col));
Mo�esz to sprawdzi�, testuj�c warto�� kolumny warunkiem IS NULL albo IS NOT NULL.
Type Nazwa wewn�trzna Uwagi -------------------------------------------------- VARCHAR(n) varchar rozmiar okre�la maksymaln� d�ugo��, nie ma tutaj wype�niania CHAR(n) bpchar wype�niane pustymi znakami do podanej d�ugo�ci TEXT text bez limitu na d�ugo�� �a�cucha BYTEA bytea zmiennej d�ugo�ci tablica bajt�w (null-byte safe) "char" char 1 znak
Je�li b�dziesz przegl�da� katalogi systemowe lub komunikaty o b��dach cz�sto spotkasz si� z podanymi powy�ej nazwami wewn�trznymi.
Pierwsze cztery typy powy�ej to tzw typy "varlena" (np. pierwsze cztery bajty na dysku to d�ugo��, po kt�rych jest data). Dlatego faktyczna d�ugo�c takiego �a�cucha jest troch� wi�ksza ni� zadeklarowany rozmiar. Te typy tak�e podlegaj� kompresji lub mog� by� przechowywane out-of-line jako TOAST, wi�c faktyczne zu�ycie miejsca na dysku mo�e by� mniejsze ni� oczekiwane.
VARCHAR(n) jest najodpowiedniejszy do przechowywania �a�cuch�w o r�nej d�ugo�ci ale okre�la on maksymaln� jego d�ugo��. TEXT jest najlepszy dla �a�cuch�w o dowolnej d�ugo�ci, nie przekraczaj�cej 1GB.CHAR(n) jast najlepszym typem do przechowywania �a�cuch�w o tej samej d�ugo�ci. CHAR(n) wype�nia dane do �adanej d�ugo�ci, podczas gdy VARCHAR(n) przechowuje jedynie dane dostarczone. BYTEA s�u�y do przechowywania danych binarnych, w szczeg�lno�ci dla danych zawieraj�cych NULL bajty. Wszystkie typy opisane tutaj maja podobne charakterystyki je�li chodzi o wydajno��.
PostgreSQL ma zaimplementowany typ SERIAL. Automatycznie tworzy sekwencj� i indeks na tej kolumnie. Dla przykladu:
CREATE TABLE person (
id SERIAL,
name TEXT
);
zostanie automatycznie przt�umaczone na:
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 );
Wi�cej informacji o sekwencjach znajdziesz w manualu o
create_sequence. Mo�esz tak�e u�y� pola OID jako
unikalnej warto�ci dla ka�dego rz�du danych. Je�li b�dziesz
potrzebowa� z backupowa� dane robi�c dump bazy i odtworzy� j�, musisz
u�yc pg_dump z opcj� -o lub polecenia COPY
WITH OIDS aby zachowa� OIDy.
Jednym z podej�� jest pobranie kolejnej warto�ci typu SERIAL z sekwencji za pomoc� funkcji nextval() zanim zostanie wstawiona, a p�niej nale�y jej u�y�. U�ywaj�c przyk�adu z tabeli z punktu 4.15.1, mo�e to wygl�da� w Perlu na przyk�ad w ten spos�b:
new_id = output of "SELECT nextval('person_id_seq')"
INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal');
B�dziesz mia� wtedy t� warto�� przechowan� w zmiennej
new_id do u�ytku w innych zapytaniach (np. jako klucz
obcy do tabeli person). Warto zwr�ci� uwag�, �e nazwa
automatycznie utworzonej sekwencji
SEQUENCE b�dzie nast�puj�ca:
<tabela>_<kolumnatypuserial>_seq,
gdzie
tabela i kolumnatypuserial s� nazwami Twojej tabeli i
Twojej kolumny typu SERIAL.
Inne rozwi�zanie to u�ycie funkcji currval() na pola typu SERIAL po dodaniu nowej warto�ci do rz�du zawieraj�cego kolumn� typu SERIAL z wstawion� domy�lnie warto�ci�, np.
INSERT INTO person (name) VALUES ('Blaise Pascal');
new_id = output of "SELECT currval('person_id_seq')";
Ostatecznie mo�esz u�y� OID
zwracanej po wykonaniu INSERT, chocia� to jest najmniej
przeno�ne rozwi�zanie.
W Perlu, wykorzystuj�c bibliotek� DBI z modu�em Edmunda Mergla
DBD::Pg, oid jest dost�pny poprzez $sth->{pg_oid_status} po
wykonaniu $sth->execute().
Nie. currval() zwraca bie��c� warto�� przypisan� przez Tw�j backend, a nie przez wszystkich u�ytkownik�w.
Aby poprawi� zbie�no�� (concurrency), warto�ci sekwencji s� podawane dzia�aj�cym transakcjom kiedy tego potrzebuj� i nie s� blokowane dop�ki transakcja si� nie zako�czy. To spowoduje przerwy w numerowaniu z przerwanych transakcji.
OID s� PostgreSQL'owym rozwi�zaniem problemu unikalnych numer�w rz�d�w. Ka�dy rz�d tworzony przez PostgreSQL otrzymuje unikalny OID. Wszystkie OIDy generowane podczas procesu uruchamianego przez skrypt initdb maj� mniejsz� warto�� ni� 16384 (na podstawie pliku backend/access/transam.h). Wszystkie OIDy tworzone przez u�ytkownika sa r�wne lub wi�ksze podanej wcze�niej warto�ci. Domy�lnie wszystkie OIDy s� unikalne nie tylko w pojedy�czej tabeli czy bazie danych ale w ca�ej instalacji PostgreSQL.
PostgreSQL u�ywa OID�w w swoim wewn�trznym systemie tabel, aby mo�na by�o je ��czy�. Te OIDy mog� byc u�ywane aby identyfikowac rz�dy w tabelach i wykorzystywa� je w z��czeniach tych tabel. Zaleca si� aby� u�ywa� typu OID aby przechowywa� warto�ci OID. Mo�esz utworzy� indeks na polu OID aby dost�p do niego by� szybszy.
OID s� przypisane do wszystkich rz�d�w z jednego g��wnego miejsca i u�ywane sa przez wszystkie bazy danych. Je�li chcia�by� zmieni� OID na co� innego, lub je�li chcia�by� zrobi� kopi� tabeli, z orginalnymi OIDami nie ma �adnego przeciwwskazania aby� to zrobi�:
CREATE TABLE new_table(old_oid oid, mycol int);
SELECT old_oid, mycol INTO new FROM old;
COPY new TO '/tmp/pgtable';
DELETE FROM new;
COPY new WITH OIDS FROM '/tmp/pgtable';
OIDy s� przechowywane jako cztero-bajtowe liczby ca�kowite i sko�cz� si� po osi�gni�ciu czterech miliard�w. Nikt jak dot�d nie zg�osi� aby co� takiego si� stalo, ale mamy zamiar pozby� si� tego ograniczenia zanim kto� to zg�osi.
TID s� u�ywane aby zidentyfikowa� konkretne rz�dy z blokami i warto�ci� ofset�w. TIDy zmieniaj� si� wraz ze zmianami rz�d�w. Sa u�ywane przez indeksy, aby wskazywa� do fizycznych rz�d�w.
W cz�ci kodu �r�d�owego i starszej dokumentacji u�ywamy termin�w, kt�re maj� bardziej og�lne znaczenie. Oto niekt�re z nich:
List� termin�w zwi�zanych z bazami danych mo�esz znale�� pod tym adresem:http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html.
Prawdopodobnie wyczerpa�a Ci si� pami�� wirtualna (virtual memory) w systemie lub Tw�j kernel ma zbyt nisko ustawione limity dla pewnych zasob�w. Spr�buj wykona� nast�puj�ce polecenia zanim uruchomisz postmaster'a:
ulimit -d 262144
limit datasize 256m
W zale�no�ci od shell'a jakiego u�ywasz jedno z tych polece� mo�e nie
zadzia�a�, ale to ustawienie pozwoli ustawi� segment danych dla
procesu znacznie wi�kszy i by� mo�e pozwoli wykona� zapytanie.
To polecenie zadzia�a dla bie��cego procesu oraz wszytkich podproces�w
utworzonych po wykonaniu polecenia. Je�li ten problem wyst�puje z
klientem SQL, poniewa� backend zwraca zbyt du�o danych,
spr�buj wykona� to polecenie przed uruchomieniem klienta.
W psql, wpisz select version();
Musisz u�y� BEGIN WORK i COMMIT
przed i po u�yciu uchwytu do du�ego obiektu, tzn. musisz nimi otoczy�
funkcje lo_open ... lo_close.
Obecnie PostgreSQL u�ywj�c "rule" zamyka uchwyt do du�ego obiektu przy ka�dym wywo�aniu "commit". Wi�c pierwsze pr�ba zrobienia czegokolwiek z uchwytem spowoduje wypisanie: invalid large obj descriptor. Kod, kt�ry do tej pory dzia�a� (przynajmniej wi�kszo�� razy) b�dzie teraz generowa� informacj� o b��dzie je�li nie b�dziesz korzysta� z transakcji.
Je�li u�ywasz interfejsu klienta jak ODBC by� mo�e
b�dziesz musia� ustawi� auto-commit off.
U�yj CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
IN sa takie wolne?W wersjach wcze�niejszych ni� 7.4 ��czymy podzapytania w outer queries
poprzez sekwencyjne przeszukiwanie wynik�w podzapytania dla ka�dego rz�du
z outer query. Je�li podzapytanie zwraca jedynie kilka rz�d�w a
zewn�trzne zapytanie zwraca ich wiele, IN jest najszybsze.
Aby przyspieszy� inne zapytania mo�na zast�pi� IN przez
EXISTS:
SELECT *
FROM tab
WHERE col IN (SELECT subcol FROM subtab)
na:
SELECT *
FROM tab
WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col)
Aby to rozwi�zanie by�o szybkie, subcol powinna by� kolumn� indeksowan�.
W wersji 7.4 i p�niejszych, IN w rzeczywisto�ci u�ywa tej samej wyrafinowanej techniki ��czenia jak normalne zapytania i jest preferowane nad u�ywaniem EXISTS.
PostgreSQL ma zaimplementowane outer join wykorzystuj�c standardow� sk�adni� SQL. Poni�ej dwa przyk�ady:
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
or
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
Te dwa identyczne zapytania ��cz� kolumn� t1.col z kolumn� t2.col, ale tak�e zwr�c� niepo��czone rz�dy w t1 (te, kt�re nie pasuj� w t2). RIGHT join doda�by niepo��czone rz�dy z tabeli t2. FULL join zwr�ci�by rz�dy plus dodatkowo wszystkie rz�dy z tabel t1 i t2. S�owo OUTER jest opcjonalne i jest dodawane domy�lnie przy LEFT, RIGHT, i FULL join'ach. Zwyk�e join'y s� nazywane INNER joins.
W poprzednich wersjach "outer joins" mog� by� zasymulowane poprzez
u�ycie slowa kluczowego
UNION i NOT IN. Dla przyk�adu, ��cz�c
tabele tab1 i tab2, nast�puj�ce zapytanie wykonuje
outer join:
SELECT tab1.col1, tab2.col2
FROM tab1, tab2
WHERE tab1.col1 = tab2.col1
UNION ALL
SELECT tab1.col1, NULL
FROM tab1
WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
ORDER BY col1
Nie ma takiej mo�liwo�ci aby w zapytaniu odpytawa� inn� baze danych poza bie��c�. Poniewa� PostgreSQL �aduje specyficzne dla bazy danych katalogi systemowe, nie jest do ko�ca jasne jak zapytanie pomi�dzy r�nymi bazami danych powinno si� zachowywa�.
contrib/dblink pozwala na wykonywanie zapyta� poprzez r�ne bazy danych wywo�uj�c odpowiednie funkcje. Oczywi�cie klient mo�e ��czy� si� z r�nymi bazami danych i ��czy� informacj� w ten spos�b uzyskan� po stronie klienta.
Mo�esz w �atwy spos�b zwraca� wiele rz�d�w lub kolumn u�ywaj�c funkcji z: http://techdocs.postgresql.org/guides/SetReturningFunctions.
PL/PgSQL przechowuje w cache zawarto�� funkcji, niepo��danym efektem tego jest to, �e gdy taka funkcja korzysta z tabel tymczasowych, kt�re s� p�niej kasowane i odtwarzane, a funkcja wywo�ywana jest ponownie,jej wywo�anie nie powiedzie si� poniewa� cachowana funkcja wci�� b�dzie wskazywa� na stara tablic� tymczasow�. Rozwi�zaniem tego problemu jest u�ywanie EXECUTE aby korzysta� z tabel tymczasowych w PL/PgSQL. To spowoduje, �e zapytanie b�dzie parsowane przy ka�dym wywo�aniu funkcji.
Jest kilka opcji aby stosowa� replikacj� typu master/slave. Ten typ pozwala jedynie masterowi na dokonywanie zmian w bazie danych, a slave mo�e jedynie te zmiany odczytywa�. Na stronie http://gborg.PostgreSQL.org/genpage?replication_research znajduje si� ich lista. Replikacja typu multi-master jest w trakcie prac, opis projektu znajduje si� pod adresem: http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
Problem mo�e by� spowodowany przez bardzo wiele rzeczy. Spr�buj najpierw przetestowa� Twoj� funkcj� w samodzielnie dzia�aj�cym programie.
Wy�lij Twoje propozycje na list� mailow� pgsql-hackers, wtedy prawdopodobnie Tw�j kod znajdzie si� w katalogu contrib/.
W wersjach PostgreSQL od numeru 7.3, funckje zwracaj�ce tabele s� w p�lni wspierane w C, PL/PgSQL i SQL. Sprawd� w Programmer's Guide aby uzyska� wi�cej informacji. Przyk�ad funkcji napisanej w C zwracaj�cej tabel� zosta� umieszczony w contrib/tablefunc.
Pliki Makefiles nie maj� dorzuconych odpowiednich zale�no�ci dla plik�w nag��wkowych (include files). Wykonaj najpierw make clean, a nast�pnie ponownie make. Je�li u�ywasz GCC mo�esz u�y� opcji --enable-depend przy wykonywaniu configure aby kompilator m�g� okre�li� zale�no�ci samodzielnie.