Raw File
FAQ_polish

                 Frequently Asked Questions (FAQ) o PostgreSQL
                                       
   Ostatnia aktualizacja: Sobota Luty 7 22:16:21 EST 2004
   
   Ostatnia aktualizacja tl/umaczenia: Piatek Marzec 5 19:31:12 EST 2004
   
   Obecny maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
   
   Tl/umaczenie: Marcin Mazurek (m.mazurek@netsync.pl)
   
   Najbardziej aktualna wersje tego dokumentu mozna znalezc pod adresem:
   http://www.PostgreSQL.org/docs/faqs/FAQ.html.
   
   Odpowiedzi na pytania dotyczace konkretnych system闚 operacyjnych
   mozna znalezc pod adresem: http://www.PostgreSQL.org/docs/index.html.
     _________________________________________________________________
   
                               Pytania og鏊ne
                                      
   1.1) Co to jest PostgreSQL? Jak to wymawiac?
   1.2) Jaka licencja chroniony jest PostgreSQL?
   1.3) Na jakich systemach Unixowych dzial/a PostreSQL?
   1.4) Na jakich nie-Unixowych systemach dzial/a PostgreSQL?
   1.5) Skad moge sciagnac PostgreSQL?
   1.6) Gdzie mozna szukac wsparcia technicznego?
   1.7) Jaka jest ostatnia dostepna wersja?
   1.8) Jaka dokumentacja jest dostepna?
   1.9) Gdzie moge znalezc informacje o znanych bl/edach czy brakujacych
   rozwiazanich?
   1.10) Jak moge sie nauczyc SQL?
   1.11) Czy PostgreSQL ma rozwiazany problem Y2K?
   1.12) Jak moge sie przyl/aczyc do grupy os鏏 bezposrednio pracujacych
   nad rozwojem PostgreSQL?
   1.13) Jak moge zgl/aszac bl/edy?
   1.14) Jak mozna por闚nac PostgreSQL w stosunku do innych DBMS?
   1.15) W jaki spos鏏 moge wesprzec finansowo PostgreSQL?
   
                            Pytania uzytkownik闚
                                      
   2.1) Czy sa jakies driwery ODBC dla PostgreSQL?
   2.2) Jakie istnieja narzedzia pozwalajace na dostep do PostgreSQL
   przez www?
   2.3) Czy istnieje jakies GUI dla PostgreSQL?
   2.4) Za pomoca jakich jezyk闚 programowania mozna sie komunikowac z
   PostgreSQL?
   
                      Pytania dotyczace administracji
                                      
   3.1) Jak moge zainstalowac PostgreSQL w innej lokalizacji niz
   /usr/local/pgsql?
   3.2) Podczas startu postmaster'a, otrzymuje komunikat: Bad System Call
   lub "core dumped". Dlaczego?
   3.3) Podczas startu postmaster'a, otrzymuje komunikat o bl/edzie:
   IpcMemoryCreate. Dlaczego?
   3.4) Podczas startu postmaster'a, otrzymuje komunikat o bl/edzie:
   IpcSemaphoreCreate. Dlaczego?
   3.5) W jaki spos鏏 moge kontrolowac pol/aczenia z innych host闚?
   3.6) Jak powinienem skonfigurowac system baz danych aby uzyskac lepsza
   wydajnosc?
   3.7) Jakie sa mozliwosci wyszukiwania bl/ed闚?
   3.8) Skad sie bierze komunikat: "Sorry, too many clients" podczas
   pr鏏y pol/aczenia sie z baza danych?
   3.9) Jakie pliki znajduja sie w pg_temp?
   3.10) Dlaczego konieczne jest przy upgradzie PostgreSQL korzystanie ze
   skrypt闚 dump i restore?
   
                       Pytania dotyczace uzytkowania
                                      
   4.1) Jaka jest r霩nica pomiedzy kursorami binarnymi (binary cursors) i
   zwykl/ymi kursorami (normal cursors)?
   4.2) Jak moge pobrac za pomoca SELECT jedynie kilka pierwszych wynik闚
   zapytania?
   4.3) Jak moge uzyskac liste wszystkich tabel czy innych rzeczy pod
   psql?
   4.4) Jak usunac kolumne z tabeli lub zmienic jej typ?
   4.5) Jaki jest maksymalny rozmiar dla rzedu, tabeli i bazy danych?
   4.6) Jak duzo miejsca w bazie danych jest potrzebne aby przechowac
   dane ze zwyczajnego pliku tekstowego?
   4.7) Jak moge sprawdzic jakie tabele, klucze, bazy danych i
   uzytkownicy sa utworzeni?
   4.8) Moje zapytania sa wolne lub nie uzywaja kluczy. Dlaczego?
   4.9) Jak moge sprawdzic w jakis spos鏏 "query optimizer" wykonuje moje
   zapytanie?
   4.10) Co to jest "R-tree index"?
   4.11) Co to jest "Genetic Query Optimizer"?
   4.12) Jak moge uzywac wyrazen regularnych w zapytaniach i zapytan
   case-insensitive w wyrazeniach regularnych? Jak korzystac z indeks闚
   dla zapytan case-insensitive?
   4.13) Jak sprawdzic w zapytaniu czy pole ma wartosc NULL?
   4.14) Jaka jest r霩nica pomiedzy r霩nymi typami tekstowymi (character
   types)?
   4.15.1) Jak moge utworzyc pole typu int, kt鏎e samo zwieksza swoja
   wartosc?
   4.15.2) Jak pobrac wartosc pola typu SERIAL po wykonaniu insert'u?
   4.15.3) Czy uzycie currval() i nextval() nie doprowadzi do "race
   condition" z innymi uzytkownikami?
   4.15.4) Dlaczego numery sekwencji nie sa ponownie uzywane przy
   przerwaniu transakcji? Skad sie biora luki w numerowaniu kolumny
   tabeli sekwencjami/SERIALem?
   4.16) Co to jest OID? Co to jest TID?
   4.17) Jakie jest znaczenie niekt鏎ych termin闚 w PostgreSQL?
   4.18) Skad bierze sie ten bl/ad: "ERROR: Memory exhausted in
   AllocSetAlloc()"?
   4.19) Jak sprawdzic jakiej wersji PostgreSQL uzywam?
   4.20) Dlaczego operacje, kt鏎e wykonuje na duzych obiektach
   "large-object" zwracaja komunikat: "invalid large obj descriptor"?
   4.21) Jak stworzyc kolumne kt鏎ej domyslna wartoscia bedzie biezacy
   czas?
   4.22) Dlaczego zapytania uzywajace IN sa takie wolne?
   4.23) Jak wykonac "outer join"?
   4.24) Jak wykonywac zapytanie uzywajace kilku baz danych jednoczesnie?
   4.25) Jak zwr鏂ic w funkcji wiele rzed闚 lub kolumn?
   4.26) Dlaczego nie moge w spos鏏 pewny tworzyc/usuwac tabel
   tymczasowych w funkcjach PL/PgSQL?
   4.27) Jakie sa mozliwosci replikacji w PostgreSQL?
   4.28) Jakie mozliwosci szyfrowania oferuje PostgreSQL?
   
                           Rozwijanie PostgreSQL
                                      
   5.1) Napisal/em wl/asna funkcje. Kiedy uzyje jej w psql, program
   zrzuca pamiec (dump core)?
   5.2) Jak moge dodac/zgl/osic nowe typy czy funkcje do PostgreSQL?
   5.3) Jak napisac funkcje C zwracajaca krotke (tuple)?
   5.4) Zmienil/em plik zr鏚l/owy. Dlaczego po rekompilacji nie widac
   zmiany?
     _________________________________________________________________
   
                               Pytania og鏊ne
                                      
    1.1) Co to jest PostgreSQL? Jak to wymawiac?
    
   PostgreSQL wymawia sie Post-Gres-kju-el. Czesto podczas rozm闚 uzywany
   jest termin "Postgres"
   
   PostgreSQL jest rozszerzeniem systemu zarzadzania bazami danych -
   POSTGRES, kolejna generacja rozwojowego prototypu DBMS. Mimo, ze
   PostgreSQL zachowal/ bardzo dobrze zbudowany model danych (data model)
   i bogaty zestaw typ闚 danych POSTGRES'a, zastapil/ PostQuel'owy jezyk
   zapytan z rozbudowanym podzbiorem jezyka SQL. PostgreSQL jest
   oprogramowaniem darmowym z dostepnymi cal/ymi zr鏚l/ami.
   
   Rozw鎩 PostgreSQL jest prowadzony przez grupe ludzi z Internetu,
   komunikujacych sie poprzez mailowe listy dyskusyjne PostgreSQL.
   Obecnym koordynatorem jest Marc G. Fournier (scrappy@PostgreSQL.org).
   (Zobacz pytanie 1.6 jak sie przyl/aczyc). Ta grupa ludzi jest
   odpowiedzialna za cal/y rozw鎩 PostgreSQL. PostgreSQL jest projektem
   nie kontrolowanym przez zadna firme, aby wziac udzial/ w jego rozwoju
   sprawdz, http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html
   
   Autorami PostgreSQL 1.01 byli Andrew Yu and Jolly Chen. Wiele innych
   os鏏 pomogl/o przy portowaniu, testowaniu, debugowaniu i rozwijaniu
   kodu. Oryginalny kod Postgresa, na kt鏎ym zostal/ oparty PostgreSQL,
   byl/ wysil/kiem student闚 oraz pracownik闚 pracujacych pod
   kierownictwem profesora Michael'a Stonebraker'a z University of
   California w Berkeley.
   
   Oryginalna nazwa oprogramowania w Berkeley byl/ Postgres. Po dodaniu
   obsl/ugi SQL w 1995, nazwa zostal/a zmieniona na Postgres95. Pod
   koniec roku 1996 nazwa zostal/a zmieniona na PostgreSQL.
   
    1.2) Jaka licencja chroniony jest PostgreSQL?
    
   PostgreSQL objety jest nastepujaca licencja:
   
   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 powyzej, jest klasyczna licencja BSD. Nie posiada ona zadnych
   restrykcji co do uzywania kodu zr鏚l/owego. Podoba nam sie i nie
   zamierzamy jej zmieniac.
   
    1.3) Na jakich systemach Unixowych dzial/a PostreSQL?
    
   PostgreSQL powinien dzial/ac na wszystkich nowych Unix-podobnych
   systemach. Platformy, kt鏎e zostal/y szczeg鏊/owo przetestowane
   podczas publikowania PostgreSQL sa wymienione w dokumentacji
   opisujacej instalacje.
   
    1.4) Na jakich nie-Unixowych systemach dzial/a PostgreSQL?
    
   Klient
   
   Mozliwa jest kompilacja bibliteki C libpq, psql oraz innych
   interfejs闚 i uruchamianie ich na platformie MS Windows. W tym wypadku
   klient jest uruchamiany na MS Windows a z serwerem komunikuje sie
   poprzez TCP/IP. Serwer moze dzial/ac na dowolnej wspieranej platformie
   Unixowej. Plik win32.mak jest dol/aczony do zr鏚el/, aby mozna byl/o
   stworzyc biblioteke libpq oraz program psql dzial/ajace w srodowisku
   Win32. PostgreSQL moze sie takze komunikowac z klientami ODBC.
   
   Serwer
   
   Serwer moze byc uruchamiany na Windows NT i Win2k uzywajac bibliotek
   Cygwin, Cygnus Unix/NT. W pliku pgsql/doc/FAQ_MSWIN znajdujacym sie w
   zr鏚l/ach lub pod adresem:
   http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN na naszych
   stronach.
   
   Obecnie prowadzone sa prace nad stworzeniem wersji dla MS Win
   NT/200/XP. Jesli chcesz sie dowiedziec o obecnym statusie tych prac
   zobacz http://techdocs.postgresql.org/guides/Windows and
   http://momjian.postgresql.org/main/writings/pgsql/win32.html.
   
   Istnieje takze port pod Novell Netware 6 dostepny pod adresem
   http://forge.novell.com.
   
    1.5) Skad mozna sciagnac PostgreSQL?
    
   Gl/闚ny serwer ftp z dostepem "anonymous" dla PostgreSQL znajduje sie
   ftp://ftp.PostgreSQL.org/pub. jesli szukasz mirror闚 sprawdz nasza
   gl/闚na strone www.
   
    1.6) Gdzie mozna szukac wsparcia technicznego?
    
   Adres gl/闚nej listy mailowej: pgsql-general@PostgreSQL.org. Jest ona
   przeznaczona dyskusjom dotyczacym spraw zwiazanych z PostgreSQL. Zeby
   zapisac sie na liste, wyslij email z nastepujacymi liniami w tresci
   maila (nie w temacie):
    subscribe
    end

   na adres: pgsql-general-request@PostgreSQL.org.
   
   Dostepna jest takze lista wysyl/ajaca digesty. Aby zapisac sie na nia,
   wyslij email na adres: pgsql-general-digest-request@PostgreSQL.org z
   trescia maila zawierajaca:
    subscribe
    end

   Digesty sa wysyl/ane do czl/onk闚 listy, kiedy na gl/闚na liste dotrze
   ok 30k wiadomosci.
   
   Dostepna jest takze lista poswiecona bl/edom znalezionym w PostgreSQL.
   Aby zapisac sie na nia wyslij email na adres:
   pgsql-bugs-request@PostgreSQL.org z trescia maila zawierajaca:
    subscribe
    end

   Lista poswiecona dyskusjom developer闚 jest dostepna pod adresem:
   pgsql-hackers-request@PostgreSQL.org Aby sie na nia zapisac wyslij na
   jej adres mail z trescia:
    subscribe
    end

   Dodatkowe informacje o listach mailowych dotyczacych PostgreSQL mozna
   znalezc na stronach WWW PostgreSQL pod adresem:
   
     http://www.PostgreSQL.org
     
   W sieci EFNet istnieje kanal/ IRC #PostgreSQL. Ja, do pol/aczenia sie
   z kanal/em uzywam Unixowego polecenia irc -c '#PostgreSQL' "$USER"
   irc.phoenix.net.
   
   Lista firm oferujacych wsparcie na zasadach komercyjnych znajduje sie
   pod adresem: http://techdocs.postgresql.org/companies.php.
   
    1.7) Jaka jest ostatnia dostepna wersja?
    
   Ostatnia dostepna wersja PostgreSQL to 7.4.1.
   
   Planujemy publikowanie kolejnych wersji co szesc do osmiu miesiecy.
   
    1.8) Jaka dokumentacja jest dostepna?
    
   Kilka manuali, stron podecznika man, oraz kilka przykl/ad闚 do
   testowania sa zal/aczone w samej dystrybucji. Znajduja sie one w
   katalogu /doc. Manual moze byc takze przegladany poprzez strony www
   pod adresem http://www.PostgreSQL.org/docs.
   
   Istnieja takze dwie ksiazki dostepne online pod adresami
   http://www.PostgreSQL.org/docs/awbook.html i
   http://www.commandprompt.com/ppbook/. Lista ksiazek o PostgreSQL,
   kt鏎e mozna kupic znajduje sie pod adresem
   http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Zbi鏎
   technicznych artykul/闚 o PostgreSQL znajduje sie pod adresem
   http://techdocs.postgresql.org/.
   
   psql posiada kilka wbudowanych polecen \d, za pomoca kt鏎ych mozna
   sprawdzic informacje dotyczace typ闚, operator闚, funkcji, agregat闚
   itd.
   
   Na naszej stronie mozna znalezc duzo wiecej dokumentacji.
   
    1.9) Gdzie mozna znalezc informacje o znanych bl/edach czy brakujacych
    rozwiazanich?
    
   PostgreSQL wspiera rozszerzony podzbi鏎 standardu SQL-92. Sprawdz
   nasza liste TODO aby znalezc informacje o znanych problemach,
   brakujacych rozwiazaniach czy przyszl/ych planach.
   
    1.10) Jak moge sie nauczyc SQL?
    
   Ksiazka o PostgreSQL http://www.PostgreSQL.org/docs/awbook.html uczy
   SQL. Jest jeszcze inna ksiazka o PostgreSQL dostepna pod adresem:
   http://www.commandprompt.com/ppbook. Dobry tutorial mozesz znalezc 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 uzytkownik闚 poleca The Practical SQL Handbook,
   Bowman, Judith S., et al., Addison-Wesley. Inni polecaja The Complete
   Reference SQL, Groff et al., McGraw-Hill.
   
    1.11) Czy PostgreSQL ma rozwiazany problem Y2K?
    
   Tak, bez problemu radzimy sobie z datami po roku 2000 AD, oraz przed
   rokiem 2000 BC.
   
    1.12) Jak moge sie przyl/aczyc do grupy os鏏 bezposrednio pracujacych nad
    rozwojem PostgreSQL?
    
   Przede wszystkim sciagnij ostatnie dostepne zr鏚l/a i przeczytaj
   dokumentacje przeznaczona dla developer闚 na naszej stronie www lub
   dostepna takze w zr鏚l/ach PostgreSQL. Nastepnie zapisz sie na listy
   mailowe pgsql-hackers i pgsql-patches. I na koniec, wysyl/aj nam
   wysokiej jakosci patch'e na liste pgsql-patches.
   
   Jest okol/o 12 os鏏, kt鏎e maja uprawnienia do commit'owania w CVS
   PostgreSQL'a. Kazdy z nich submitowal/ tak wiele wysokiej jakosci
   patchy, ze stal/o sie niemozliwe dla obecnych commiter闚 byc z nimi na
   biezaco, wiec musielismy im ufac i miec pewnosc, ze ich poprawki sa
   wysokiej jakosci.
   
    1.13) Jak moge zgl/aszac bl/edy?
    
   Zajrzyj na strone PostgreSQL BugTool, na kt鏎ej opisane sa wskaz闚ki
   jak zgl/aszac informacje o bl/edach.
   
   Zajrzyj takze na nasz ftp ftp://ftp.PostgreSQL.org/pub, aby sprawdzic
   czy nie ma nowszych wersji PostgreSQL czy patchy.
   
    1.14) Jak mozna por闚nac PostgreSQL w stosunku do innych DBMS?
    
   Jest kilka sposob闚 oceny softwaru: mozliwosci, wydajnosc, stabilnosc,
   wsparcie i cena.
   
   Mozliwosci
          PostgreSQL posiada mozliwosci dostepne w duzych, komercyjnych
          systemach DBMS, takie jak transakcje, podzapytania
          (subselects), triggery, widoki, klucze obce, referential
          integrity, oraz wyrafinowany system blokowania. Mamy takze
          wl/asciowsci kt鏎ych inni nie posiadaja, jak typy definiowane
          przez uzytkownika, dziedziczenie, rules, multi-version
          concurrency control, kt鏎a redukuje problemy z blokowaniem
          (lock contention).
          
   Wydajnosc
          Wydajnosc PostgreSQL jest podobna do innych komercyjnych i open
          source baz danych. W niekt鏎ych sytuacjach jest szybszy w
          niekt鏎ych wolniejszy. W por闚nianiu do MySQL lub mniejszych
          baz danych jestesmy szybsi przy wielu uzytkownikach,
          skomplikowaych zapytaniach i duzym obciazeniu podczas. MySQL
          jest szybszy dla prostych SELECT闚 wykonywanych przez niewielu
          uzytkownik闚. Spowodowane jest to narzutem, kt鏎y sie pojawia
          przy transakcjach. Oczywiscie MySQL nie ma wiekszosci z
          rozwiazan opisanych powyzej w sekcji Mozliwosci . PostgreSQL
          zostal/ stworzony z mysla o stabilnosci, oraz szerokiej gamie
          mozliwosci, ale mimo to staramy sie w kazdej wersji poprawiac
          jego wydajnosc. Ciekawe por闚nanie PostgreSQL i MySQL mozna
          znalezc pod adresem
          http://openacs.org/philosophy/why-not-mysql.html Dodatkowo,
          MySQL jest firma, kt鏎a dystrybuuje jej produkty poprzez zasade
          Open Source i wymaga wykupienia licencji w przypadku tworzenia
          close-source software, co ie ma miejsca w przypadku PostgreSQL.
          
   Stabilnosc
          Zdajemy sobie sprawe, ze DBMS musi byc stabilny, w przeciwnym
          wypadku jest bez wartosci. Staramy sie publikowac kod stabilny,
          dobrze przetestowany, z minimum mozliwych bl/ed闚. Kazde
          wydanie poprzedza co najmniej miesiac test闚 wersji beta.
          Patrzac na historie wydan PostgreSQL widac, ze dostarczamy
          stabilne, dobrze sprawdzone wersje, kt鏎e sa gotowe do uzycia w
          srodowisku produkcyjnym. Myslimy, ze proces publikowania
          kolejnych wersji opracowany przez nas jest jednym z lepszych
          wsr鏚 innych tw鏎c闚 oprogramowania bazodanowego.
          
   Wsparcie
          Dzieki naszym listom mailowym masz dostep do duzej liczby
          programist闚 i uzytkownik闚, kt鏎zy pomagaja rozwiazac kazdy
          napotkany problem. Chociaz nie mozemy gwarantowac znalezienia
          rozwiazania danego problemu, nie r霩nimy sie w tym od innych
          komercyjnych system闚 DBMS. Bezposredni kontakt z
          programistami, uzytkownikami, dokumentacja i kodem zr鏚l/owym
          sprawiaja, ze wsparcie oferowane PostgreSQL niejednokrotnie
          jest lepsze niz w innych systemach DBMS. Istnieje takze
          mozliwosc skorzystania z komercyjnego wsparcia dla tych,
          kt鏎ych takiego rozwiazania potrzebuja. (Sprawdz ten punkt
          FAQ.)
          
   Cena
          Korzystanie z PostgreSQL jest darmowe, zar闚no w przypadku
          komercyjnym jak i niekomercyjnym. Mozesz korzystac z naszego
          kodu zr鏚l/owego w Twoim produkcie bez zadnych ograniczen, poza
          tymi wymienionymi w licencji BSD przytoczonej powyzej.
          
    1.15) W jaki spos鏏 moge wesprzec finansowo PostgreSQL?
    
   PostgreSQL korzysta z najlepszej infrastruktury od samego poczatku
   istnienia projektu, czyli roku 1996 kiedy rozpoczelismy prace.
   Wszystko to zawdzieczamy Marc'owi Fournier'owi, kt鏎y stworzyl/ ta
   infrastrukture i zarzadza nia od lat.
   
   Wysokiej jakosci infrastruktura jest bardzo wazna dla kazdego projektu
   open-source. Zapobiega przerwom w rozwoju projektu i jakimkolwiek
   przestojom.
   
   Oczywiscie korzystanie z wysokiej jakosci infrastruktury nie jest
   tanie. Istnieje wiele r霩nych miesiecznych, czy jednorazowych
   wydatk闚, kt鏎e trzeba ponosic aby wszystko dzial/al/o jak nalezy.
   Jesli Ty, badz Twoja firma moze wspom鏂 finansowo rozw鎩 PostgreSQL
   odwiedz adres: http://store.pgsql.com/shopping/ gdzie opisane jest jak
   to zrobic.
   
   Chociaz na stronie wspomniana jest nazwa PostgreSQL Inc, "datki" sa
   przeznaczone jedynie na rozw鎩 projektu PostgreSQL i nie sa
   przeznaczane na finansowanie jakiejkolwiek firmy. Jesli wolisz, mozesz
   wysl/ac czek na adres kontaktowy.
     _________________________________________________________________
   
   Jesli mozesz sie pochwalic udanymi wdrozeniami PostgreSQL, prosimy
   abys zgl/osil/ nam to na stronie: http://advocacy.postgresql.org.
   
                           User Client Questions
                                      
    2.1) Czy sa jakies driwery ODBC dla PostgreSQL?
    
   Dostepne sa dwa driwery ODBC: PsqlODBC i OpenLink ODBC.
   
   Mozesz pobrac PsqlODBC z adresu
   http://gborg.postgresql.org/project/psqlodbc/projdisplay.php
   
   OpenLink ODBC moze byc pobrany z adresu: http://www.openlinksw.com.
   Wsp鏊/pracuje ze standardowym oprogramowaniem klienckim ODBC wiec w
   ten spos鏏 mozesz korzystac z PostgreSQL ODBC dostepnego na kazdej
   pltaformie kt鏎a wspiera (Win, Mac, Unix, VMS).
   
   Autorzy beda prawdopodobnie sprzedawac ten produkt osobom kt鏎e
   wymagaja komercyjnego wsparcia, ale wersja darmowa bedzie zawsze
   dostepna. Wszystkie pytania mozesz wysyl/ac na adres:
   postgres95@openlink.co.uk.
   
    2.2) Jakie istnieja narzedzia pozwalajace na dostep do PostgreSQL przez
    www?
    
   Dobry podrecznik dla poczatkujacych o dostepie do bazy danych przez
   www mozesz znalezc pod adresem: http://www.webreview.com
   
   Do integracji z www, swietnym rozwiazaniem jest PHP. Mozesz znalezc
   wiecej informacji na ten temat pod adresem http://www.php.net.
   
   Wiele os鏏 w przypadku skomplikowanych rozwiazan uzywa Perl'a i
   modul/u CGI.pl lub mod_perl.
   
    2.3) Czy istnieje jakies GUI dla PostgreSQL?
    
   Tak, istnieje kilka interfejs闚 graficznych dla PostgreSQL. Wsr鏚 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 takze PHPPgAdmin (
   http://phppgadmin.sourceforge.net/ ), webowy interfejs dla PostgreSQL.
   
   Wiecej informacji na ten temat znajduje sie pod adresem See
   http://techdocs.postgresql.org/guides/GUITools.
   
    2.4) Za pomoca jakich jezyk闚 programowania mozna sie komunikowac z
    PostgreSQL?
    
   Najbardziej popularne jezyki posiiadaja wl/asny interfejs dla
   PostgreSQL. Sprawdz liste rozszerzen dla intersujacego Ciebie jezyka
   programowania.
   
   Ze zr鏚l/ami PostreSQL dystrubuowane sa interfejsy dla nastepujacych
   jezyk闚 programowania:
     * C (libpq)
     * Embedded C (ecpg)
     * Java (jdbc)
     * Python (PyGreSQL)
     * TCL (libpgtcl)
       
   Inne interfejsy sa dostepne pod adresem: http://gborg.postgresql.org w
   sekcji Drivers/Interfaces.
     _________________________________________________________________
   
                      Pytania dotyczace administracji
                                      
    3.1) Jak moge zainstalowac PostgreSQL w innej lokalizacji niz
    /usr/local/pgsql?
    
   Uzyj opcji --prefix podczas uruchamiania skryptu configure.
   
    3.2) Podczas startu postmaster'a, otrzymuje komunikat o bl/edzie: Bad
    System Call lub "core dumped". Dlaczego?
    
   Ten bl/ad moze byc wynikiem wielu problem闚, ale na poczatek sprawdz
   czy masz zainstalowane rozszerzenia systemu V w jadrze systemu.
   PostgreSQL wymaga do pracy zainstalowanej obsl/ugi pamieci dzielonej i
   semafor闚.
   
    3.3) Podczas startu postmaster'a, otrzymuje komunikat o bl/edzie:
    IpcMemoryCreate. Dlaczego?
    
   Albo nie masz poprawnie skonfigurowanej obsl/ugi pamieci dzielonej w
   jadrze systemu, albo musisz zwiekszyc jej dostepny rozmiar. Dokl/adna
   ilosc jaka potrzebujesz jest zalezna od architektury systemu na jakim
   pracujesz, jak duzo bufor闚 oraz jak duzo proces闚 backendu
   skonfigurowal/es dla postmaster'a. Dla wiekszosci system闚, z domyslna
   liczba bufor闚 i proces闚 potrzebujesz minimum w przyblizeniu 1MB.
   Zobacz PostgreSQL Administrator's Guide gdzie szczeg鏊/owo zostal/o
   opisane wykorzystanie pamieci dzielonej i semafor闚.
   
    3.4) Podczas startu postmaster'a, otrzymuje komunikat o bl/edzie:
    IpcSemaphoreCreate. Dlaczego?
    
   Jesli tresc bl/edu brzmi: IpcSemaphoreCreate: semget failed (No space
   left on device) oznacza to, ze jadro systemu nie jest skonfigurowane
   do obsl/ugi wystarczajacej liczby semafor闚. Postgres wymaga jednego
   semafor'a na potencjalny jeden proces backend. Tymczasowym
   rozwiazaniem jest uruchomienie programu postmaster z mniejsza
   maksymalna liczba proces闚 backend. Uzyj opcji -N z parameterem
   mniejszym od domyslnego - 32. Bardziej trwal/ym rozwiazaniem jest
   zwiekszenie parametr闚 SEMMNS i SEMMNI jadra twojego systemu.
   
   Niedzial/ajace semafory moga spowodowac niepoprawne zamkniecie systemu
   w czasie intensywnego korzystania z bazy.
   
   Jesli tresc bl/edu jest inna, moze to oznaczac, ze obsl/uga semafor闚
   nie zostal/a wl/aczona do jadra wcale. Zobacz PostgreSQL
   Administrator's Guide po bardziej szczeg鏊/owe informacje o pamieci
   dzielonej i semaforach.
   
    3.5) W jaki spos鏏 moge kontrolowac pol/aczenia z innych host闚?
    
   Domyslnie PostgreSQL pozwala jedynie na pol/aczenia za pomoca socket闚
   Unixowych z lokalnego hosta. Inne hosty nie beda mogl/y sie pol/aczyc
   z serwerem dop鏦i nie zostanie dodana opcja -i do postmaster'a, oraz
   nie umozliwi sie autoryzacji na podstawie adresu host闚 modyfikujac
   odpowiednio plik $PGDATA/pg_hba.conf. To zmiany pozwola na pol/aczenia
   TCP/IP.
   
    3.6) Jak powinienem skonfigurowac system baz danych aby uzyskac lepsza
    wydajnosc?
    
   Indeksy bez watpienia moga przyspieszyc wykonywanie zapytan. Polecenie
   EXPLAIN pozwala zobaczyc jak PostgreSQL interpretuje Twoje zapytanie i
   kt鏎e indeksy sa uzywane.
   
   Jesli wykonujesz bardzo duzo INSERT闚, moze warto je wykonac za pomoca
   jednego duzego pliku uzywajac polecenia COPY. Jest to duzo szybsze niz
   pojedyncze INSERTy. Po drugie polecenia SQL nie zawarte w bloku
   okreslajacym transakcje - BEGIN WORK/COMMIT, sa traktowane jako
   pojedyncza transakcja. Rozwaz wykonanie kilku polecen/zdan SQL w
   jednym bloku transakcji. To redukuje narzut nakl/adany przez
   transakcje. Przy duzych zmianach w danych, warto usunac i stworzyc na
   nowo indeksy.
   
   Jest kilka opcji pozwalajacych na poprawienie wydajnosci. Mozesz
   wyl/aczyc fsync() poprzez uruchomienie postmaster'a z opcjami -o -F.
   To spowoduje, ze fsync() nie bedzie zrzucal/ danych na dysk po kazdej
   transakcji.
   
   Mozesz takze uruchomic postmaster'a z opcja -B aby zwiekszyc wielkosc
   pamieci dzielonej uzywanej przez procesy backend闚. Jesli ustawisz ta
   wartosc zbyt wysoko i przekroczysz limity ustawione przez kernel na
   pamiec dzielona, postmaster moze sie nie uruchomic. Kazdy bufor
   zajmuje 8K a domyslna ilosc bufor闚 to 64.
   
   Mozesz takze uzyc opcji -S dla backendu aby zwiekszyc maksymalna
   wartosc pamieci uzywana przez proces backendu podczas sortowania.
   Opcja -S jest ustawiana wartoscia podawana w kilobajtach, domyslna
   wartosc to 512K.
   
   Mozesz takze uzyc polecenia CLUSTER aby pogrupowac dane w tabelach wg
   indeksu. Zobacz opis polecenia CLUSTER w manualu zeby dowiedziec sie
   wiecej.
   
    3.7) Jakie sa mozliwosci wyszukiwania bl/ed闚?
    
   PostgreSQL ma kilka mozliwosci na raportowanie informacji o jego
   statusie, kt鏎e moga byc przydatne przy debugowaniu procesu.
   
   Przede wszystkim uruchom skrypt configure z opcja --enable-cassert,
   wiele funkcji assert() monitoruja postep procesu backend i zatrzymuja
   program kiedy wydarzy sie cos nieoczekiwanego.
   
   Zar闚no postmaster jak i postgres maja kilka opcji do debugowania. Za
   kazdym razem kiedy uruchamiasz postmaster'a, upewnij sie, ze wysyl/asz
   standardowe wyjscie i error do pliku z logami, np. w ten spos鏏:
    cd /usr/local/pgsql
    ./bin/postmaster >server.log 2>&1 &

   To utworzy plik server.log w gl/闚nym katalogu PostgreSQL. Ten plik
   zawiera pozyteczne informacje o problemach i bl/edach, kt鏎e
   wydarzyl/y sie podczas pracy serwera. Postmaster posiada opcje -d,
   kt鏎a pozwala na raportowanie bardzo szczeg鏊owych informacji. Do
   opcji -d podajemy liczbe, kt鏎a okresla szczeg鏊/owosc wysyl/anych
   informacji. Musisz miec swiadomosc, ze wysoki poziom logowania bedzie
   powodowal/ tworzenie bardzo duzych plik闚 z logami.
   
   Jesli postmaster nie zostal/ uruchomiony, mozesz uruchomic
   postgres'owy backend z linii polecen, i uruchomic Twoje polecenie SQL
   bezposrednio na nim. Taki spos鏏 jest polecany jedynie w przypadku
   debugowania. Zwr鏂 uwage, ze w tym wypadku zapytanie konczy znak nowej
   linii a nie srednik. Jesli skompilowal/es z opcjami debugowania mozesz
   uzyc debuggera aby sprawdzic co sie dzieje. Poniewz backend nie
   zostal/ uruchomiony przez postmaster'a, nie dzial/a w identycznym
   srodowisku, co oznacza ze powt鏎zenie warunk闚 w jakich wystapil/y
   problemy moze byc problemem.
   
   Jesli postmaster dzial/a, uruchom psql w jednym z okien, nastepnie
   znajdz PID procesu postgres uzywanego przez psql. Uzyj debuggera aby
   do PID'u postgres'a. Mozesz ustawiac pul/apki (breakpoints) w
   debuggerze i wykonywac zapytania z psql. Jesli debugujesz uruchamianie
   postgres'a, mozesz ustawic zmienna PGOPTIONS="-W n", nastepnie
   uruchomic psql. Opcja ta pozwoli spowolnic uruchomienie na n sekund
   abys m鏬l/ sie pol/aczyc z procesem za pomoca debugera, ustawic
   jakiekolwiek pul/apki i kontynuowac proces uruchamiania.
   
   postgres moze byc uruchamiany z opcjami -s, -A i -t, kt鏎e moga byc
   bardzo przydatne przy debuggowaniu i ocenie wydajnosci.
   
   Mozesz takze skompilowac z profilingiem aby zobaczyc jakie funkcje ile
   czasu wykonuja sie. Pliki profilowane dla backendu zostana umieszczone
   w katalogu pgsql/data/base/dbname. Pliki profilu klienta zostana
   umieszczone w biezacym katalogu klienta. Linux wymaga aby kompilowac z
   opcja -DLINUX_PROFILE aby profilowanie odbywal/o sie poprawnie.
   
    3.8) Skad sie bierze komunikat: "Sorry, too many clients" podczas pr鏏y
    pol/aczenia sie z baza danych?
    
   Musisz zwiekszyc limit ilosci jednoczesnych proces闚 bacekendu dla
   procesu postmaster'a.
   
   Domyslny limit to 32 procesy. Mozesz go zwiekszyc przez restart
   postmaster z odpowiednia wartoscia ustawiana opcje -N w pliku
   postgresql.conf.
   
   Wez pod uwage, ze jesli zwiekszysz wartosc podana w opcji -N na wiecej
   niz 32 musisz takze zwiekszyc wartosc w opcji -B ponad jej domyslna
   wartosc 64; wartosc -B musi byc co najmniej dwa razy wieksza od
   wartosci podanej w opcji -N, a prawdopodobnie powinna byc w
   rzeczywistosci jeszcze wieksza dla optymalnej wydajnosci. Dla duzej
   liczby proces闚 backendu na pewno zauwazysz, ze trzeba zwiekszyc r霩ne
   parametry jadra Unixa. Rzeczy, kt鏎e pownienes sprawdzic to maksymalna
   liczba blok闚 pamieci dzielonej, SHMMAX; maksymalna liczba semafor闚,
   SEMMNS oraz SEMMNI; maksymalna liczba proces闚, NPROC; maksymalna
   liczba proces闚 na jednego uzytkownika, MAXUPRC; i maksymalna liczba
   otwartych plik闚, NFILE oraz NINODE. Pow鏚 dla kt鏎ego PostgreSQL ma
   limit na maksymalna liczbe proces闚 backendu to obawa o wyczerpanie
   zasob闚 systemu.
   
    3.9) Jakie pliki znajduja sie w pg_temp?
    
   Katalog ten zawiera tymczasowe pliki utworzone przez executor. Dla
   przykl/adu, jesli jakas operacja sortowania jest wymagana do wykonania
   ORDER BY, a samo sortowanie wymaga wiecej miejsca niz parametr
   backendu -S ustawil/ do wykorzystania, wtedy tymczasowe pliki sa
   uzywane do przechowywania tych danych.
   
   Pliki tymczasowe powinny byc usuniete automatycznie, ale mogl/o sie to
   nie stac jesli proces backendu w miedzyczasie nie zakonczyl/ sie
   poprawnie podczas operacji sortowania. Jesli w danym momencie nie
   dzial/aja zadne procesy backend闚 mozesz spokojnie usunac pliki
   pg_tempNNN.NN.
   
    3.9) Dlaczego konieczne jest przy upgradzie PostgreSQL korzystanie ze
    skrypt闚 dump i restore?
    
   Tw鏎cy PostgreSQL dokonuja jedynie mal/ych zmian pomiedzy mal/ymi
   upgradami wersji, np z 7.2 do 7.2.1, wtedy upgrade nie wymaga
   korzystania z dump i restore. Przy wiekszych zmianach, np. z wersji
   7.2 do 7.3, czesto zmianymaja wpl/yw na format przechowywanych danych.
   Zmiany te sa na tyle skomplikowane, ze nie utrzymujemy zgodosci z
   poprzednimi wersjami PostgreSQL. dump pozwala na wydostanie danych w
   takiej postaci, w kt鏎ej l/atwe jest ich zaimportowanie do nowszych
   wersji bez kl/opotu.
   
   W wydaniach gdzie zmiany nie dotycza formatu danych na dysku, mozna
   wykorzystac skryptu pg_upgrade, do upgradu bez uzycia dump/restore.
   Dokumentacja do danego wydania zawiera informacje czy mozliwe jest
   uzycie pg_upgrade.
     _________________________________________________________________
   
                         Pytania dotyczace uzywania
                                      
    4.1) Jaka jest r霩nica pomiedzy kursorami binarnymi (binary cursors) i
    zwykl/ymi kursorami (normal cursors)?
    
   Zobacz w manualu opis polecenia DECLARE.
   
    4.2) Jak moge pobrac za pomoca SELECT jedynie kilka pierwszych wynik闚
    zapytania?
    
   Zobacz w manualu opis polecenia FETCH lub uzyj polecenia SELECT ...
   LIMIT....
   
   Nawet jesli chesz pobrac kilka pierwszych rzed闚 z wyniku zapytania,
   cal/e zapytanie musi zostac wykonane. Byc moze powinienes skorzystac z
   polecenia ORDER BY. Jesli istnieje indeks kt鏎y odpowiada polom
   okreslonym przez ORDER BY, PostgreSQL moze wykorzystac jedynie kilka
   pierwszych rzed闚, byc moze bedzie koniecznosc wykonania zapytania do
   momentu az zostana znalezione pozadane wyniki.
   
   Aby otrzymac losowy rzad, uzyj:
    SELECT col
    FROM tab
    ORDER BY random()
    LIMIT 1;
        

    4.3) Jak moge uzyskac liste wszystkich tabel czy innych rzeczy pod psql?
    
   Mozesz sprawdzic zawartosc zr鏚el/ psql, a konkretnie plik
   pgsql/src/bin/psql/describe.c. Zawiera on polecenia SQL kt鏎e generuja
   wyniki komend z backslashem. Mozesz takze uruchomic psql z opcja -E
   wtedy po wykonaniu polecenia z backslashem wyswietlane bedzie
   zapytanie, kt鏎e w rzeczywistosci jest wykonywane.
   
    4.4) Jak usunac kolumne z tabeli lub zmienic jej typ?
    
   DROP COLUMNT zostal/o dodane w wersji 7.3 przy poleceniu ALTER TABLE
   DROP COLUMN. We wczesniejszych wersjach mozesz zrobic tak:
         BEGIN;
         LOCAL TABLE old_table;
    SELECT ...  -- wybierz wszystkie kolumny poza ta jedna kt鏎ej chcesz sie pozbyc
    INTO TABLE new_table
    FROM old_table;
    DROP TABLE old_table;
    ALTER TABLE new_table RENAME TO old_table;

   Aby zmienic typ danych kolumny mozesz zrobic 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;
        
    4.5) Jaki jest maksymalny rozmiar dla rzedu, tabeli i bazy danych?
    
   Oto wszystkie ograniczenia:
    Maksymalny rozmiar dla bazdy danych?     nieograniczony ( istnieja
         bazy danych o wielkosci 32 TB databases )
    Maksymalny rozmiar dla tabeli?           32 TB
    Maksymalny rozmiar dla rzedu?            1.6 TB
    Maksymalny rozmiar pola?                 1 GB
    Maksymalna liczba rzed闚 w tabeli?       nieograniczona
    Maksymalna liczba kolumn w tabeli?       250-1600 w zalezonosci od typ闚 kolumn
    Makasymalna liczba indeks闚 na tabeli?   nieograniczona

   Oczywiscie "nieograniczony" nie jest prawda tak do konca, istnieja
   ograniczenia wynikajace z dostepnego miejsca na dysku, pamieci/swapa.
   Kiedy wielkosci te beda bardzo duze moze odbic sie to na wydajnosci.
   
   Maksymalny rozmiar tabeli, czyli 32 TB nie wymaga od systemu
   operacyjnego wsparcia dla duzych plik闚. Duze tabele sa przechowywane
   jako pliki o rozmiarze 1 GB, wiec ograniczenia co do wielkosci plik闚
   narzucone przez system plik闚 nie sa istotne.
   
   Masymalny rozmiar tabeli i maksymalna liczba kolumn moze byc
   zwiekszona jesli zwiekszymy domyslny rozmiar bloku (block size) do
   32k.
   
    4.6) Jak duzo miejsca w bazie danych jest konieczne aby przechowywac dane
    ze zwyczajnego pliku tekstowego?
    
   Baza danych PostgreSQL moze potrzebowac do pieciu razy wiecej miejsca
   na przechowywanie danych z plik闚 tekstowych niz ich objetosc.
   
   Jako przykl/ad mozemy rozwazyc plik skl/adajacy sie z 100,000 linii
   zbudowanych z liczby cal/kowitej oraz opisu tekstowego w kazdej.
   Zal/霩my, ze srednio kazdy l/ancuch tekstu w linii zajmuje 20 bajt闚.
   Cal/y plik powinien zajmowac ok. 2.8 MB. Rozmiar pliku bazy danych w
   PostgreSQL zawierajacego te dane mozna oszacowac na okol/o 6.4MB:
    36 bajt闚: nagl/闚ek kazdego rzedu w przyblizeniu)
    24 bajty:  jedno pole int i jedno pole typu text
   + 4 bajty:  wkaznik na stronie do krotki
   --------------------------------------------------
    64 bajty w jednym rzedzie

        Strona danych w PostgreSQL zajmuje 8192 bajt闚 (8 KB), wiec:

   8192 bajt闚 na strone
   ---------------------   =  128 rzed闚 na jedna strone w bazie (zaokraglone w d鏊/)
     64 bajt闚 na rzad

   100000 rzed闚 danych
   -----------------------  =  782 stron w bazie danych (zaokraglone w g鏎e)
      128 rzed闚 na strone

782 stron w bazie * 8192 bajt闚 na strone  =  6,406,144 bajt闚 (6.4 MB)

   Indeksy nie powoduja duzego narzutu na zajmowane miejsce, ale
   zawieraja pewne dane, wiec w pewnych przypadkach moga byc cal/kiem
   duze.
   
   NULLe sa przechowywane jako mapy bitowe, wiec uzywaja bardzo mal/o
   miejsca.
   
    4.7) Jak moge sprawdzic jakie tabele, klucze, bazy danych i uzytkownicy sa
    utworzeni?
    
   psql ma cal/kiem duza ilosc polecen z backslashem aby wydobyc takie
   informacje. Wprowadz \? aby zobaczyc ich spis. Istnieja takze tablice
   systemowe rozpoczynajace sie od pg_, zawierajace interesujace Ciebie
   informacje. Wykonanie psql -l pokaze spis wszystkich baz danych.
   
   Obejrzyj takze plik pgsql/src/tutorial/syscat.source. Zawiera on wiele
   z zapytan typu SELECT, kt鏎e sa potrzebne aby wydobyc informacje z
   tablic systemowych.
   
    4.8) Moje zapytania sa wolne lub nie uzywaja kluczy. Dlaczego?
    
   Indeksy nie sa uzywane automatycznie przez kazde z zapytan. Ideksy sa
   uzywane jedynie gdy tabela jest odpowiedniego rozmiaru, wiekszego niz
   wymagany minimalny, a zapytanie wybiera jedynie mal/y procent
   zawartosci tabeli. Wynika to z tego, ze losowy dostep do dysku
   powodowany przez ideksowane poszukiwanie jest czasami wolniejsze niz
   poszukiwanie sekwencyjne bez uzycia kluczy.
   
   Zeby zdecydowac czy indeks powinien byc uzywany, PostgreSQL musi miec
   statystyki dotyczace danej tabeli. Sa one gromadzone przez uzycie
   polecenia VACUUM ANALYZE, lub poprostu ANALYZE. uzywajac statystyk,
   optymalizator wie ile rzed闚 jest w tabeli i moze lepiej okreslic czy
   indeksy powinny byc uzyte. Statystyki moga byc takze pomocne w
   okresleniu najlepszej kolejnosci wykonania zl/aczenia (join) i jego
   sposobu. Gromadzenie statystyk powinno sie odbywac w okreslonych
   interwal/ach czasu poniewaz dane w tabelach zmieniaja sie.
   
   Indeksy nie sa zazwyczaj uzywane przez ORDER BY lub przy wykonywaniu
   zl/aczen (join). Sekwencyjne przeszukiwanie po kt鏎ym nastepuje
   sortowanie jest zazwyczaj szybsze nie wyszukiwanie za pomoca indeksu
   na duzej tabeli.
   
   Jakkolwiek LIMIT w pol/aczeniu z ORDER BY czesto bedzie wykorzystywal/
   indeksy poniewaz jedynie mal/a czesc z tabeli jest zwracana. W
   rzeczywistosci, chociaz MAX() i MIN() nie uzywaja indeks闚, mozliwe
   jest aby zwr鏂ic te wartosci uzywajac indeks闚 poprzez uzycie ORDER BY
   i LIMIT.
    SELECT col
    FROM tab
    ORDER BY col [ DESC ]
    LIMIT 1;
        
   Jesli uwazasz, ze optimizer myli sie wybierajac sequential scan, uzyj
   SET enable_seqscan TO 'off' i uruchom testy aby sprawdzic czy wtym
   wypadku zapytanie bedzie szybciej wykonywane.
   
   Kiedy uzywa sie operator闚 dopasujacych takich jak LIKE lub ~, indeksy
   beda uzywane jedynie w pewnych wypadkach:
     * Poczatek wyszukiwania jest oparty na poczatku l/ancucha tekstu.
          + wzorce LIKE nie moga sie zaczynac %
          + dopasowania operatorem ~ (dopasowania regularne) musza sie
            zaczynac znakiem specjalnym ^.
     * Poczatek wyszukiwania nie moze sie zaczynac od klas znak闚, np.
       [a-e].
     * Case-insensitive searches such as ILIKE and ~* do not utilise
       indexes. Instead, use functional indexes, which are described in
       section 4.12.
     * Standardowe locale C musi byc uzyte przy wykonywaniu initdb
       
    4.9) Jak moge sprawdzic w jakis spos鏏 "query optimizer" wykonuje moje
    zapytanie?
    
   Zobacz manual dla polecenia EXPLAIN.
   
    4.10) Co to jest "R-tree index"?
    
   Indeks R-tree jest uzywany do indeksowania danych przestrzennych.
   Indeks hasuujacy nie nadaje sie do wyszukiwania odlegl/osci. Natomiast
   indeks typu B-tree moze wyszukiwac odleglosci jedynie w
   jednowymiarowych przestrzeniach. R-tree indeks radzi sobie z
   przestrzeniami wielo-wymiarowymi. Dla przykl/adu, jesli zostanie
   zal/ozony indeks typu R-tree na polu typu point, system moze bardziej
   wydajnie odpowiadac na zapytania typu "select all points within a
   bounding rectangle."
   
   Zr鏚l/owym dokumentem opisujacym oryginalnie projektowanie R-tree
   indeks闚 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 mozesz znalezc takze w pracy Stonebraker'a "Readings in
   Database Systems".
   
   Wbudowane indeksy R-trees radza sobie w wielobokami i boxes.
   Teoretycznie, indeksy R-tree moga byc rozszerzone o mozliwosci
   indeksowania w wiecej wymiarowych przestrzeniach. W praktyce,
   rozbudowa indeks闚 R-tree wymaga troche pracy, a w tej chwili nie
   dysponujemy jakakolwiek dokumentacja jak to zrobic.
   
    4.11) Co to jest "Genetic Query Optimizer"?
    
   Modul/ GEQO ma za zadanie przyspieszenie optymalizacji zapytan l/aczac
   wiele tabel za pomoca algorytm闚 genetycznych (Genetic Algorithm
   (GA)). Pozwala na uzywanie duzych zapytan l/aczacych tabele (join
   queries) bez wykorzystywania zasobozernego wyszukiwania.
   
    4.12) Jak moge uzywac wyrazen regularnych w zapytaniach i zapytan
    case-insensitive w wyrazeniach regularnych? Jak korzystac z indeks闚 dla
    zapytan case-insensitive?
    
   Operator ~ moze byc wykorzystywany do wyszukiwania za pomoca wyrazen
   regularnych, a ~* do wyszukiwania case-insensitive z wyrazeniami
   regularnymi. Wariant case-insensitive dla LIKE zostal/ nazwany ILIKE.
   
   Por闚nania case-insensitive sa zazwyczaj wykonywane w nastepujacy
   spos鏏:
    SELECT *
    FROM tab
    WHERE lower(col) = 'abc'

   W tym wypadku standardowe indeksy nie beda uzywane. Mozesz utworzyc
   indeks funkcyjny, poprzez:
    CREATE INDEX tabindex on tab (lower(col));

    4.13) Jak sprawdzic w zapytaniu czy pole ma wartosc NULL?
    
   Mozesz to sprawdzic, testujac wartosc kolumny warunkiem IS NULL albo
   IS NOT NULL.
   
    4.14) Jaka jest r霩nica pomiedzy r霩nymi typami tekstowymi (character
    types)?
    
Type            Nazwa wewnetrzna   Uwagi
--------------------------------------------------
VARCHAR(n)      varchar            rozmiar okresla maksymalna dl/ugosc, nie matutaj wypel/niania
CHAR(n)         bpchar             wypel/niane pustymi znakami do podanej dl/ugosci
TEXT            text               bez limitu na dl/ugosc l/ancucha
BYTEA           bytea              zmiennej dl/ugosci tablica bajt闚 (null-byte safe)
"char"          char                      1 znak

   Jesli bedziesz przegladac katalogi systemowe lub komunikaty o bl/edach
   czesto spotkasz sie z podanymi powyzej nazwami wewnetrznymi.
   
   Pierwsze cztery typy powyzej to tzw typy "varlena" (np. pierwsze
   cztery bajty na dysku to dl/ugosc, po kt鏎ych jest data). Dlatego
   faktyczna dl/ugosc takiego l/ancucha jest troche wieksza niz
   zadeklarowany rozmiar. Te typy takze podlegaja kompresji lub moga byc
   przechowywane out-of-line jako TOAST, wiec faktyczne zuzycie miejsca
   na dysku moze byc mniejsze niz oczekiwane.
   
   VARCHAR(n) jest najodpowiedniejszy do przechowywania l/ancuch闚 o
   r霩nej dl/ugosci ale okresla on maksymalna jego dl/ugosc. TEXT jest
   najlepszy dla l/ancuch闚 o dowolnej dl/ugosci, nie przekraczajacej
   1GB.
   
   CHAR(n) jast najlepszym typem do przechowywania l/ancuch闚 o tej samej
   dl/ugosci. CHAR(n) wypel/nia dane do zadanej dl/ugosci, podczas gdy
   VARCHAR(n) przechowuje jedynie dane dostarczone. BYTEA sl/uzy do
   przechowywania danych binarnych, w szczeg鏊nosci dla danych
   zawierajacych NULL bajty. Wszystkie typy opisane tutaj maja podobne
   charakterystyki jesli chodzi o wydajnosc.
   
    4.15.1) Jak moge utworzyc pole kt鏎e samo zwieksza swoja wartosc?
    
   PostgreSQL ma zaimplementowany typ SERIAL. Automatycznie tworzy
   sekwencje i indeks na tej kolumnie. Dla przykladu:
    CREATE TABLE person (
        id   SERIAL,
        name TEXT
    );

   zostanie automatycznie prztl/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 );

   Wiecej informacji o sekwencjach znajdziesz w manualu o
   create_sequence. Mozesz takze uzyc pola OID jako unikalnej wartosci
   dla kazdego rzedu danych. Jesli bedziesz potrzebowal/ z backupowac
   dane robiac dump bazy i odtworzyc ja, musisz uzyc pg_dump z opcja -o
   lub polecenia COPY WITH OIDS aby zachowac OIDy.
   
    4.15.2) Jak pobrac wartosc pola typu SERIAL po wykonaniu insert'u?
    
   Jednym z podejsc jest pobranie kolejnej wartosci typu SERIAL z
   sekwencji za pomoca funkcji nextval() zanim zostanie wstawiona, a
   p霩niej nalezy jej uzyc. Uzywajac przykl/adu z tabeli z punktu 4.15.1,
   moze to wygladac w Perlu na przykl/ad w ten spos鏏:
    new_id = output of "SELECT nextval('person_id_seq')"
    INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal');

   Bedziesz mial/ wtedy ta wartosc przechowana w zmiennej new_id do
   uzytku w innych zapytaniach (np. jako klucz obcy do tabeli person).
   Warto zwr鏂ic uwage, ze nazwa automatycznie utworzonej sekwencji
   SEQUENCE bedzie nastepujaca: <tabela>_<kolumnatypuserial>_seq, gdzie
   tabela i kolumnatypuserial sa nazwami Twojej tabeli i Twojej kolumny
   typu SERIAL.
   
   Inne rozwiazanie to uzycie funkcji currval() na pola typu SERIAL po
   dodaniu nowej wartosci do rzedu zawierajacego kolumne typu SERIAL z
   wstawiona domyslnie wartoscia, np.
    INSERT INTO person (name) VALUES ('Blaise Pascal');
    new_id = output of "SELECT currval('person_id_seq')";

   Ostatecznie mozesz uzyc OID zwracanej po wykonaniu INSERT, chociaz to
   jest najmniej przenosne rozwiazanie. W Perlu, wykorzystujac biblioteke
   DBI z modul/em Edmunda Mergla DBD::Pg, oid jest dostepny poprzez
   $sth->{pg_oid_status} po wykonaniu $sth->execute().
   
    4.15.3) Czy uzycie currval() i nextval() nie doprowadzi do race condition z
    innymi uzytkownikami?
    
   Nie. currval() zwraca biezaca wartosc przypisana przez Tw鎩 backend, a
   nie przez wszystkich uzytkownik闚.
   
    4.15.4) Dlaczego numery sekwencji nie sa ponownie uzywane przy przerwaniu
    transakcji? Skad sie biora luki w numerowaniu kolumny tabeli
    sekwancjami/SERIALem?
    
   Aby poprawic zbieznosc (concurrency), wartosci sekwencji sa podawane
   dzial/ajacym transakcjom kiedy tego potrzebuja i nie sa blokowane
   dop鏦i transakcja sie nie zakonczy. To spowoduje przerwy w numerowaniu
   z przerwanych transakcji.
   
    4.16) Co to jest OID? Co to jest TID?
    
   OID sa PostgreSQL'owym rozwiazaniem problemu unikalnych numer闚
   rzed闚. Kazdy rzad tworzony przez PostgreSQL otrzymuje unikalny OID.
   Wszystkie OIDy generowane podczas procesu uruchamianego przez skrypt
   initdb maja mniejsza wartosc niz 16384 (na podstawie pliku
   backend/access/transam.h). Wszystkie OIDy tworzone przez uzytkownika
   sa r闚ne lub wieksze podanej wczesniej wartosci. Domyslnie wszystkie
   OIDy sa unikalne nie tylko w pojedynczej tabeli czy bazie danych ale w
   cal/ej instalacji PostgreSQL.
   
   PostgreSQL uzywa OID闚 w swoim wewnetrznym systemie tabel, aby mozna
   byl/o je l/aczyc. Te OIDy moga byc uzywane aby identyfikowac rzedy w
   tabelach i wykorzystywac je w zl/aczeniach tych tabel. Zaleca sie abys
   uzywal/ typu OID aby przechowywac wartosci OID. Mozesz utworzyc indeks
   na polu OID aby dostep do niego byl/ szybszy.
   
   OID sa przypisane do wszystkich rzed闚 z jednego gl/闚nego miejsca i
   uzywane sa przez wszystkie bazy danych. Jesli chcial/bys zmienic OID
   na cos innego, lub jesli chcial/bys zrobic kopie tabeli, z orginalnymi
   OIDami nie ma zadnego przeciwwskazania abys to zrobil/:
        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 sa przechowywane jako cztero-bajtowe liczby cal/kowite i skoncza
   sie po osiagnieciu czterech miliard闚. Nikt jak dotad nie zgl/osil/
   aby cos takiego sie stalo, ale mamy zamiar pozbyc sie tego
   ograniczenia zanim ktos to zgl/osi.
   
   TID sa uzywane aby zidentyfikowac konkretne rzedy z blokami i
   wartoscia ofset闚. TIDy zmieniaja sie wraz ze zmianami rzed闚. Sa
   uzywane przez indeksy, aby wskazywac do fizycznych rzed闚.
   
    4.17) Jakie jest znaczenie niekt鏎ych termin闚 w PostgreSQL?
    
   W czesci kodu zr鏚l/owego i starszej dokumentacji uzywamy termin闚,
   kt鏎e maja bardziej og鏊ne znaczenie. Oto niekt鏎e z nich:
     * table, relation, class
     * row, record, tuple
     * column, field, attribute
     * retrieve, select
     * replace, update
     * append, insert
     * OID, serial value
     * portal, cursor
     * range variable, table name, table alias
       
   Liste termin闚 zwiazanych z bazami danych mozesz znalezc pod tym
   adresem:http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/
   glossary/glossary.html.
   
    4.18) Skad bierze sie ten bl/ad "ERROR: Memory exhausted in
    AllocSetAlloc()"?
    
   Prawdopodobnie wyczerpal/a Ci sie pamiec wirtualna (virtual memory) w
   systemie lub Tw鎩 kernel ma zbyt nisko ustawione limity dla pewnych
   zasob闚. Spr鏏uj wykonac nastepujace polecenia zanim uruchomisz
   postmaster'a:
    ulimit -d 262144
    limit datasize 256m

   W zaleznosci od shell'a jakiego uzywasz jedno z tych polecen moze nie
   zadzial/ac, ale to ustawienie pozwoli ustawic segment danych dla
   procesu znacznie wiekszy i byc moze pozwoli wykonac zapytanie. To
   polecenie zadzial/a dla biezacego procesu oraz wszytkich podproces闚
   utworzonych po wykonaniu polecenia. Jesli ten problem wystepuje z
   klientem SQL, poniewaz backend zwraca zbyt duzo danych, spr鏏uj
   wykonac to polecenie przed uruchomieniem klienta.
   
    4.19) Jak sprawdzic jakiej wersji PostgreSQL uzywam?
    
   W psql, wpisz select version();
   
    4.20) Dlaczego operacje, kt鏎e wykonuje na duzych obiektach "large-object"
    zwracaja komunikat: "invalid large obj descriptor"?
    
   Musisz uzyc BEGIN WORK i COMMIT przed i po uzyciu uchwytu do duzego
   obiektu, tzn. musisz nimi otoczyc funkcje lo_open ... lo_close.
   
   Obecnie PostgreSQL uzywjac "rule" zamyka uchwyt do duzego obiektu przy
   kazdym wywol/aniu "commit". Wiec pierwsze pr鏏a zrobienia czegokolwiek
   z uchwytem spowoduje wypisanie: invalid large obj descriptor. Kod,
   kt鏎y do tej pory dzial/al/ (przynajmniej wiekszosc razy) bedzie teraz
   generowal/ informacje o bl/edzie jesli nie bedziesz korzystal/ z
   transakcji.
   
   Jesli uzywasz interfejsu klienta jak ODBC byc moze bedziesz musial/
   ustawic auto-commit off.
   
    4.21) Jak stworzyc kolumne kt鏎ej domyslna wartoscia bedzie biezacy czas?
    
   Uzyj CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );

    4.22) Dlaczego zapytania uzywajace IN sa takie wolne?
    
   W wersjach wczesniejszych niz 7.4 l/aczymy podzapytania w outer
   queries poprzez sekwencyjne przeszukiwanie wynik闚 podzapytania dla
   kazdego rzedu z outer query. Jesli podzapytanie zwraca jedynie kilka
   rzed闚 a zewnetrzne zapytanie zwraca ich wiele, IN jest najszybsze.
   Aby przyspieszyc inne zapytania mozna zastapic 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 rozwiazanie byl/o szybkie, subcol powinna byc kolumna
   indeksowana.
   
   W wersji 7.4 i p霩niejszych, IN w rzeczywistosci uzywa tej samej
   wyrafinowanej techniki l/aczenia jak normalne zapytania i jest
   preferowane nad uzywaniem EXISTS.
   
    4.23) Jak wykonac "outer join"?
    
   PostgreSQL ma zaimplementowane outer join wykorzystujac standardowa
   skl/adnie SQL. Ponizej dwa przykl/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 l/acza kolumne t1.col z kolumna t2.col,
   ale takze zwr鏂a niepol/aczone rzedy w t1 (te, kt鏎e nie pasuja w t2).
   RIGHT join dodal/by niepol/aczone rzedy z tabeli t2. FULL join
   zwr鏂il/by rzedy plus dodatkowo wszystkie rzedy z tabel t1 i t2.
   Sl/owo OUTER jest opcjonalne i jest dodawane domyslnie przy LEFT,
   RIGHT, i FULL join'ach. Zwykl/e join'y sa nazywane INNER joins.
   
   W poprzednich wersjach "outer joins" moga byc zasymulowane poprzez
   uzycie slowa kluczowego UNION i NOT IN. Dla przykl/adu, l/aczac tabele
   tab1 i tab2, nastepujace 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

    4.24) Jak wykonywac zapytanie uzywajace kilku baz danych jednoczesnie?
    
   Nie ma takiej mozliwosci aby w zapytaniu odpytawac inna baze danych
   poza biezaca. Poniewaz PostgreSQL l/aduje specyficzne dla bazy danych
   katalogi systemowe, nie jest do konca jasne jak zapytanie pomiedzy
   r霩nymi bazami danych powinno sie zachowywac.
   
   contrib/dblink pozwala na wykonywanie zapytan poprzez r霩ne bazy
   danych wywol/ujac odpowiednie funkcje. Oczywiscie klient moze l/aczyc
   sie z r霩nymi bazami danych i l/aczyc informacje w ten spos鏏 uzyskana
   po stronie klienta.
   
    4.25) Jak zwr鏂ic w funkcji wiele rzed闚 lub kolumn?
    
   Mozesz w l/atwy spos鏏 zwracac wiele rzed闚 lub kolumn uzywajac
   funkcji z:
   http://techdocs.postgresql.org/guides/SetReturningFunctions.
   
    4.26) Dlaczego nie moge w spos鏏 pewny tworzyc/usuwac tabel tymczasowych w
    funkcjach PL/PgSQL?
    
   PL/PgSQL przechowuje w cache zawartosc funkcji, niepozadanym efektem
   tego jest to, ze gdy taka funkcja korzysta z tabel tymczasowych, kt鏎e
   sa p霩niej kasowane i odtwarzane, a funkcja wywol/ywana jest
   ponownie,jej wywol/anie nie powiedzie sie poniewaz cachowana funkcja
   wciaz bedzie wskazywac na stara tablice tymczasowa. Rozwiazaniem tego
   problemu jest uzywanie EXECUTE aby korzystac z tabel tymczasowych w
   PL/PgSQL. To spowoduje, ze zapytanie bedzie parsowane przy kazdym
   wywol/aniu funkcji.
   
    4.27) Jakie sa mozliwosci replikacji w PostgreSQL?
    
   Jest kilka opcji aby stosowac replikacje typu master/slave. Ten typ
   pozwala jedynie masterowi na dokonywanie zmian w bazie danych, a slave
   moze jedynie te zmiany odczytywac. Na stronie
   http://gborg.PostgreSQL.org/genpage?replication_research znajduje sie
   ich lista. Replikacja typu multi-master jest w trakcie prac, opis
   projektu znajduje sie pod adresem:
   http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
   
    4.28) Jakie mozliwosci szyfrowania oferuje PostgreSQL?
    
     * contrib/pgcrypto zawiera wiele funkcji za pomoca, kt鏎ych mozemy
       uzywac kryptografii w zapytaniach SQL.
     * Aby szyfrowac transmisje od klienta do serwera, ten musi miec
       ustawiona opcje ssl na true w pliku postgresql.conf, odpowiedni
       wpis host lub hostssl musi wystepowac w pliku pg_hba.conf, oraz
       sslmode nie moze byc wyl/aczone w kliencie. (Warto zwr鏂ic uwage,
       ze mozliwe jest takze uzywanie transport闚 szyfrujac闚 przez
       strony trzecie, takie jak stunnel lub ssh, poza natywnym wsparciem
       dla SSL przez PostgreSQL).
     * Hasl/a uzytkownik闚 bazy danych sa automatycznie szyfrowane od
       wersji 7.3. W poprzednich wersjach, nalezy ta funkcjonalnosc
       poprzez wl/aczenie opcji PASSWORD_ENCRYPTION w postgresql.conf.
     * Serwer moze dzial/ac uzywajac szyfrowanego systemu plik闚.
       
                           Rozwijanie PostgreSQL
                                      
    5.1) Napisal/em wl/asna funkcje. Kiedy uzyje jej w psql, program zrzuca
    pamiec (dump core)?
    
   Problem moze byc spowodowany przez bardzo wiele rzeczy. Spr鏏uj
   najpierw przetestowac Twoja funkcje w samodzielnie dzial/ajacym
   programie.
   
    5.2) Jak moge dodac/zgl/osic nowe typy czy funkcje do PostgreSQL?
    
   Wyslij Twoje propozycje na liste mailowa pgsql-hackers, wtedy
   prawdopodobnie Tw鎩 kod znajdzie sie w katalogu contrib/.
   
    5.3) Jak napisac funkcje C zwracajaca krotke (tuple)?
    
   W wersjach PostgreSQL od numeru 7.3, funckje zwracajace tabele sa w
   pelni wspierane w C, PL/PgSQL i SQL. Sprawdz w Programmer's Guide aby
   uzyskac wiecej informacji. Przykl/ad funkcji napisanej w C zwracajacej
   tabele zostal/ umieszczony w contrib/tablefunc.
   
    5.4) Zmienil/em plik zr鏚l/owy. Dlaczego po rekompilacji nie widac zmiany?
    
   Pliki Makefiles nie maja dorzuconych odpowiednich zaleznosci dla
   plik闚 nagl/闚kowych (include files). Wykonaj najpierw make clean, a
   nastepnie ponownie make. Jesli uzywasz GCC mozesz uzyc opcji
   --enable-depend przy wykonywaniu configure aby kompilator m鏬l/
   okreslic zaleznosci samodzielnie.
back to top