Ostatnia aktualizacja: Thu Apr 18 00:44:51 EDT 2002
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/faq-english.html.
Odpowiedzi na pytania dotyczące konkretnych systemów operacyjnych można znaleźć pod adresem: http://www.PostgreSQL.org/users-lounge/docs/faq.html.
IN są takie wolne?PostgreSQL wymawia się Post-Gres-kju-el.
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 poniżej jak się przyłączyć). Ta grupa ludzi jest odpowiedzialna za cały rozwój PostgreSQL.
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-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.
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 C, 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 win31.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: MS Windows FAQ na naszych stronach. Nie planujemy tworzyć portu przeznaczonego docelowo dla platformy Microsoft.
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://www.postgresql.org/users-lounge/commercial-support.html.
Ostatnia dostępna wersja PostgreSQL to 7.2.1.
Planujemy publikowanie kolejnych wersji co cztery miesiące.
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/users-lounge/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://www.postgresql.org/books/. 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, aggregató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, mając pewność że są to poprawki 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, tzn. sześciu lat. 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óznych 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://www.pgsql.com/pg_goodies 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.
PsqlODBC jest dołączony do źródeł. Więcej informacji na jego temat możesz znaleźć pod adresem: ftp://ftp.PostgreSQL.org/pub/odbc/.
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 plaformie 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.
Sprawdź także rozdział o ODBC w "Programmer's Guide".
Dobry podręcznik dla początkujących o dostępie do bazy danych przez www możesz znaleźć pod adresem: http://www.webreview.com
Inny znajduje się pod adresem: http://www.phone.net/home/mwm/hotlist/.
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.
Mamy całkiem miły interfejs graficzny, który został nazwany pgaccess i jest on dostarczany jako część źródeł. pgaccess posiada także generator raportów. Można go znaleźć pod adresem http://www.flex.ro/pgaccess
Udostępniliśmy także ecpg, który jest "embedded SQL query language interface" dla języka C.
Mamy wsparcie dla:
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 powodowany 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.
W wersjach PostgreSQL wcześniejszych niż 6.5, maksymalna liczba backendów była ustawiona na 64, a zmiana tej wartości wymaga rekompliacji po zmianie stałej MaxBackendId w pliku include/storage/sinvaladt.h.
Są to 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ż paratmetr 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.
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.
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.
Nie mamy zaimplementowanego ALTER TABLE DROP COLUMN, ale możesz zrobić tak:
SELECT ... -- wybierz zawartość wszystkich kolumn 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;
Oto wszystkie ograniczenia:
Maksymalny rozmiar dla bazdy danych? nieograniczony ( istnieją bazy danych o wielkości 500 GB databases )
Maksymalny rozmiar dla tabeli? 16 TB
Maksymalny rozmiar dla rzędu? nieograniczony w 7.1 i późniejszych
Maksymalny rozmiar pola? 1 GB w 7.1 and later
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 16 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.
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ł indeksów poniewąz jedynie mała częśc z tabeli jest zwracana.Kiedy używa się operatorów dopasujących takich jak LIKE lub ~, indeksy będą używane jedynie jeśli początek wyszukiwania jest oparty na początku łańcucha tekstu. Dlatego, aby używac indeksów, dopasowania operatorem LIKE nie mogą się zaczynać %, a dopasowania operatorem ~ (dopasowania regularne) muszą się zaczynać znakiem specjalnym ^.
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 i jest dostępny w PostgreSQL 7.1 i późniejszych wersjach.
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 -------------------------------------------------- "char" char 1 znak CHAR(#) bpchar wypełniane pustymi znakami do podanej długości VARCHAR(#) varchar rozmiar określa maksymalną długość, nie ma tutaj wypełniania TEXT text bez limitu na długość łańcucha BYTEA bytea zmiennej długości tablica bajtów (null-byte safe)
Jeśli będziesz przeglądać katalogi systemowe lub komunikaty o błędach często spotkasz się z podanymi powyżej nazwami wewnętrznymi.
Ostatnie 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.
CHAR() jast najlepszym typem do przechowywania łańcuchów o tej samej długości. VARCHAR() 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. BYTEA służy do przechowywania danych binarnych, w szczególności dla danych zawierających NULL bajty.
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://www.comptechnews.com/~reaster/dbdesign.html
Jeśli używasz wersji starszej niż 7.1, upgrade może rozwiązać ten problem. Jest także mozliwe, że po prostu 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?Obecnie łączymy podzapytania w outer queries poprzez sekwencyjne
przeszukiwanie wyników podzapytania dla każdego rzędu z outer query.
Można to ominąć zastępując IN przez
EXISTS:
SELECT *
FROM tab
WHERE col1 IN (SELECT col2 FROM TAB2)
na:
SELECT *
FROM tab
WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
Mamy zamiar poprawić to ograniczenie w przyszłych wydaniach.
PostgreSQL 7.1 i późniejsze wersje mają zaimplementowane outer join wykorzystując standardową składnie 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ć.
Oczywiście klient może łączyć się z różnymi bazami danych i łączyć informację w ten sposób uzyskaną.
Możesz zwracać zbiory z funkcji PL/pgSQL używając refcursors. Zobacz http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html, sekcję 23.7.3.3.
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/.
To wymaga wysiłku tak olbrzymiego, że nawet autorzy nigdy tego nie prubowali, chociaż z zalożeń wynika, że jest to możliwe.
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