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-2008, 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:
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.