mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c7099997ac
postgres/doc/FAQ_hungarian
Bruce Momjian a9c28a6124 Hungarian FAQ is text, not HTML, so remove it.
2003-02-18 17:20:37 +00:00

1121 lines
49 KiB
Plaintext
Raw Blame History

PostgreSQL GyIK
Utolsó módosítás dátuma: 2002 Okt 20.
Fordítás aktualizálása: 2003 január
A GyIK karbantartója: Bruce Momjian (pgman@candle.pha.pa.us)
Fordító: Hornyák László (hornyakl.NOSPAM@inf.elte.hu)
A legfrissebb verzió itt érhető el (angol):
http://www.PostgreSQL.org/docs/faq-english.html.
Legfrissebb magyar nyelvű verzió:
http://www.rootshell.be/~hornyakl/downloads/postgres_faq/
Platform specifikus kérdések:
http://www.PostgreSQL.org/users-lounge/docs/faq.html.
_________________________________________________________________
Általános kérdések
1.1) Mi a PostgreSQL? Hogy kell kimondani?
1.2) Mik a PostgreSQL felhasználási feltételei?
1.3) Milyen UNIX operációs rendszereken fut PostgreSQL?
1.4) Milyen nem UNIX operációs rendszerek elérhetőek?
1.5) Hogyan tudok PostgreSQL-t szerezni?
1.6) Hogyan kapok terméktámogatást?
1.7) Melyik a legfrissebb kiadás?
1.8) Milyen dokumentáció áll rendelkezésre?
1.9) Hogyan találok információt hibákról vagy hiányzó funkcionalításról?
1.10) Hogy tanuljam meg az SQL nyelvet?
1.11) A PostgreSQL 2000. év kompatibilis?
1.12) Hogyan lehet csatlakozni a fejlesztő csapathoz?
1.13) Hogyan küldjek hibajelentést?
1.14) Milyen a PostgreSQL más DBMS-ekkel összehasonlítva?
1.15) Hogyan tudom üzletileg segiteni a PostgreSQL-t?
Felhasználói kliens kérdések
2.1) Van ODBC meghajtó PostgreSQL-hez?
2.2) Milyen eszközök állnak rendelkezésre PostgreSQL Web fejlesztésekhez?
2.3) Van a PostgreSQL-hez grafikus felhasználói felület ? Riport
generátor? Beágyazott lekérdező nyelv felület?
2.4) Milyen programozási nyelvekkel lehet elérni a PostgreSQL szervert?
Adminisztrációs kérdések
3.1) Hogyan tudom a PostgreSQL-t /usr/local/pgsql -től eltérő helyre
installálni?
3.2) AMikor elindítom a postmaster-t, egy "Bad System Call"-t vagy core
dump-ot kapok. Miért?
3.3) Amikor megpróbálom inditani a postmaster-t, "IpcMemoryCreate" hibákat
kapok. Miért?
3.4) Amikor megpróbálom inditani a postmaster-t, "IpcSemaphoreCreate" hibákat
kapok. Miért?
3.5) Hogyan tudom kontrollálni a más gépekről érkező kapcsolat kéréseket?
3.6) Hogyan tudom nagyobb teljesítményre hangolni az adatbázisomat?
3.7) Milyen hibakereső lehetőségek érhetőek el?
3.8) Miért kapok "Sorry, too many clients" hibát csatlakozásnál?
3.9) Mi van pgsql_tmp könyvtárban?
3.10) Miért kell dumpolni és újratölteni PostgreSQL kiadás váltásánál?
Működtetési kérdések
4.1) Mi a különbség a bináris és a normál kurzorok között?
4.2) Hogyan tudom select-elni a lekérdezés első pár sorát?
4.3) Hogy tudom kilistázni a táblákat vagy más dolgokat a PostgreSQL-ben?
4.4) Hogyan tudok eltávolítani egy oszlopot egy táblából?
4.5) Mi a maximális mérete egy sornak, egy táblának vagy egy adatbázisnak?
4.6) Mekkora adatbázis lemez terület szükséges egy tipikus szöveg állomány
tárolásához?
4.7) Hogy tudhatom meg milyen táblák, indexek, adatbázisok vagy felhasználók
vannak definiálva?
4.8) A lekérdezéseim lassúak, vagy nem használják az indexeket. Miért?
4.9) Hogy tudom ellenőrizni, hogy optimalizálta a lekérdezés optimalizáló a
lekérdezésem?
4.10) Mi az R-tree index?
4.11) Mi a Genetic Query Optimizer?
4.12) Hogyan tudok regexp keresést és case-insensitive regexp keresést
használni? Hogyan tudok indexet használni case-insensitive kereséshez?
4.13) Hogyan tudom észlelni egy lekérdezésban, ha egy mező NULL?
4.14) Mi a különbség a különböző karaktertípusok között?
4.15.1) Hogyan tudok létrehozni automatikusan növekvő értékű mezőt?
4.15.2) Hogyan kaphatom meg egy SERIAL beszúrás értékét?
4.15.3) A currval() és a nextval() nem teremt holtpont veszélyes helyzetet
a felhasználók között?
4.15.4) Miért nem használódnak fel újra a sequence számok tranzakció abort
esetén?
Miért vannak problémák a serial oszlopok számozásával?
4.16) Mi a OID? Mi a TID?
4.17) Mi a PostgreSQL-ben használt kifejezések jelentése?
4.18) Miért kapom ezt a hibát: "ERROR: Memory exhausted in
AllocSetAlloc()"?
4.19) Hogyan tudhatom meg PostgreSQL, milyen verziót futtatok?
4.20) Miért kapok "invalid large obj descriptor" hibát nagy objektumok
kezelésénél?
4.21) Hogy hozhatok létre olyan oszlopot, aminek alapértelmezett érétke a
jelenlegi idő?
4.22) Miért olyan lassúak az al-lekérdezéseim IN-nel?
4.23) Hogyan tudok outer join-t végrehajtani?
4.24) Hogyan tudok több adatbázison végrehajtani lekérdezést?
4.25) Hogy tudok több soros vagy oszlopos eredményt visszaadni egy
funkcióból?
4.26) Miért nem tudom megbizhatóan létrehozni és törölni az átmeneti
táblákat a PL/pgSQL funkciókban?
4.27) Milyen replikációs lehetőségek vannak?
4.28) Milyen kódolási lehetőségek vannak?
A PostgreSQL kiterjesztése
5.1) Írtam egy felhasználói funkciót. Miért core dumpol az adatbázis amikor
használom?
5.2) Hogyan lehet új adattípusokat és funkciókat hozzáadni a PostgreSQL
disztribúcióhoz?
5.3) Hogyan lehet olyan C funkciót írni, ami Tuple-t ad vissza?
(több soros több oszlopos eredmények)
5.4) Megváltoztattam egy forrás állományt. Miért nem változik a bináris
újrafordítás után?
_________________________________________________________________
Általános kérdések
1.1) Mi a PostgreSQL? Hogy kell kimondani?
Így ejstd ki: Post-Gres-Q-L.
(Vagy talán inkább töltsd le a kis mp3-at a PostgreSQL homepage-ről)
A PostgreSQL a POSTGRES adatbázis management rendszer egy kiegészítése,
ami egy következő generációs DBMS kutatási prototípus. Megtartja a
POSTGRES adatmodellét és gazdag adattípus választékát, de a PostQuel
lekérdező nyelvet az SQL egy kiterjesztett verziójával helyettesíti.
A PostgreSQL szabad és a teljes forráskód hozzáférhető.
A PostgreSQL fejlesztését egy csapat végzi, amelynek minden tagja
megtalálható a PostgreSQL fejlesztői levelezési listán. A jelenlegi
koordinátor Marc G. Fournier (scrappyp@PostgreSQL.org). Ez a csapat
felelős minden fejlesztésért.
A PostgreSQL 1.01 alkotói Andrew Yu és Jolly Chen voltak. Sokan
járultak hozzá portolással, teszteléssel, hibakereséssel és
fejlesztéssel. Az eredeti Postgres kód, amiből a PostgreSQL származik
Michael Stonebraker professzor irányítása alatt fejlesztettek az
egyetem programozói, tanulói és végzett tanulói.
A szoftver ereeti neve Postgres volt. Amikor SQL funkcionalítással
egészítették ki 1995-ben, a nevét Postgres95-re változtatták. 1996
végén kapta mai nevét.
1.2) Mik a PostgreSQL felhasználási feltételei?
Az eredeti angol copyright szöveg:
--------------------
PostgreSQL is subject to the following COPYRIGHT:
PostgreSQL Data Base Management System
Portions copyright (c) 1996-2002, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
The above is the BSD license, the classic open-source license. It has
no restrictions on how the source code may be used. We like it and
have no intention of changing it.
--------------------
Ami nagyon leegyszerűsítve azt jelenti, hogy jogod van használni a
szoftvert mindenféle ellenszolgáltatás (pénz, stb) nélkül, a forrás
kódot módosíthatod, és továbbadhatod, DE semmilyen, a szoftver használatából
következő károsodásért nem vállal garanciát a fejlesztő.
A fenti a BSD licensz, egy klasszikus nyilt-forráskód licensz. Nem
tartalmaz megszorításokat arra, hogy a forráskódot hogyan használod fel.
Kedveljük ezt a licensz formát és nem áll szándékunkban megváltoztatni.
1.3) Milyen UNIX operációs rendszereken fut PostgreSQL?
Általában minden UNIX-kompatibilis operációs rendszer képes arra hogy
futtassa a PostgreSQL-t. Azokat a platformokat, amiken tesztelték a
kiadást megtalálhatod a installációs utasítások között.
1.4) Milyen nem UNIX operációs rendszerek elérhetőek?
Kliens
A libpq C függvénykönyvtárat, a psql-t és más felületeket le lehet úgy
fordítani, hogy fussanak MS Windows operációs rendszereken. Ebben az esetben
a kliens MS Windows-on fut és TCP/IP segítségével kommunikál a Unixon
futó szerverrel. A "win32.mak" állomány a kiadás része, ennek segítségével
lehet Win32 platformokra lefordítani a libpq-t és a psql-t. A PostgreSQL
ODBC kliensekkel is képes kommunikálni.
Szerver
Az adatbázis szerver Cygwin segítségével fut Windows NT és Win2k
rendszereken. További információ található a pgsql/doc/FAQ_MSWIN
állományban és a MS Windows FAQ-ban a következő helyen:
http://www.PostgreSQL.org/docs/faq-mswin.html.
Natív MS Windows NT/2000/XP portok jelenleg fejlesztés alatt állnak.
1.5) Hogyan tudok PostgreSQL-t szerezni?
Az elsődleges anonim ftp oldal:
ftp://ftp.PostgreSQL.org/pub.
A tükör oldalak listája megtalálható a fő weboldalunkon.
1.6) Hogyan kapok terméktámogatást?
Az elsődleges lista a pgsql-general@postgresql.org. Ez használható
a PostgreSQL-lel kapcsolatos párbeszédekre. Ha fel szeretnél íratkozni,
küldj egy levelet a következő tartalommal (nem tárggyal) a
pgsql-general-request@postgresql.org címre:
subscribe
end
Van egy hibákkal kapcsolatos levelezési lista is:
pgsql-bugs-request@PostgreSQL.org a következő tartalommal:
subscribe
end
A fejleszt?i levelezési lista:
pgsql-hackers-request@PostgreSQL.org a következő tertalommal:
subscribe
end
Egyéb levelezési listák találhatóak a weboldalunkon:
http://www.PostgreSQL.org
Van egy IRC csatorna is #PostgreSQL néven ahol felteheted kérédseid.
A következő unix paranccsal csatlakozhatsz:
irc -c '#PostgreSQL' "$USER" irc.phoenix.net.
A kereskedelmi terméktámogatást nyújtó cégek listája elérhetö itt:
http://www.PostgreSQL.org/users-lounge/commercial-support.html
1.7) Melyik a legfrissebb kiadás?
A legfrissebb PostgreSQL kiadás a 7.3.
A tervek szerint minden negyedik hónapban van új kiadás.
1.8) Milyen dokumentáció áll rendelkezésre?
Számos kézikönyv, man oldalak és kis teszt példák találhatóak a kiadásban
a doc/ könyvtár alatt. Az interneten is olvashatod a dokumentációt a
következő címen:
http://www.PostgreSQL.org/users-lounge/docs/.
Két PostgreSQL könyv érhető el az interneten a
http://www.PostgreSQL.org/docs/awbook.html és a
http://www.commandprompt.com/ppbook/ címeken.
A megvásárolható könyvek listája itt található:
http://www.ca.PostgreSQL.org/books/.
A PostgreSQL-lel kapcsolatos technikai jellegű cikkek gyűjteménye:
http://techdocs.PostgreSQL.org/.
A psql parancs rendelkezik néhány \d utasítással, amellyekkel listázhatóak
az operátorok, a funkciók, stb.
A website is tartalmaz további dokumentációkat.
1.9) Hogyan találok információt hibákról vagy hiányzó funkcionalításról?
A PostgreSQLaz SQL-92 szabvány egy kiegészítése. Nézd meg a TODO listákat
ha érdekelnek az ismert hibák.
1.10) Hogy tanuljam meg az SQL nyelvet?
A PostgreSQL könyv a http://www.PostgreSQL.org/docs/awbook.html
címen tartalmaz SQL alapokat. Elérhető egy másik SQL könyv is a
http://www.commandprompt.com/ppbook címen. Egy szép oktató anyag
található a http://www.intermedia.net/support/sql/sqltut.shtm,
a http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM
és a http://sqlcourse.com oldalakon.
Egy másik lehetőség a "Tanítsd magad 21 nap alatt SQL-re, második
kiadás" a http://members.tripod.com/er4ebus/sql/index.htm.
Sok felhasználónak tetszett a gyakorlati SQL könyv ("The Practical
SQL Handbook").
1.11) A PostgreSQL 2000. év kompatibilis?
Igen, könnyedén kezeli a 2000 utáni és időszámításunk elött 2000 elötti
dátumokat is.
1.12) Hogyan lehet csatlakozni a fejlesztő csapathoz?
Elösször is töltsd le a forráskódot, és olvasd el a PostgreSQL
fejlesztői dokumnetációt a web oldalunkon vagy a kiadásban. Ezután
íratkozz fel a pgsql-hackers és a pgsql-patches levelezési listákra.
Végül pedig küldj be magas szinvonalú patch-eket a pgsql-patches listára.
Van egy pár ember, akiknek commit privilégiumuk a PostgreSQL CVS fán.
Ők olyan sok magas szinvonalú patch-et küldtek be, hogy az addigi
csapat már nem tudta követni, és nem volt kétségünk arról, hogy a
patch-ek amiket ők küldenek jó minőségű.
1.13) Hogyan küldjek hibajelentést?
Látogass el a BugTool oldalra:
http://www.PostgreSQL.org/bugs/bugs.php
Itt megtalálod követendő utasításokat.
Ellenőrizd az ftp oldalunkon is, hogy nincs-e újabb verzió vagy folt.
ftp://ftp.PostgreSQL.org/pub
1.14) Milyen a PostgreSQL más DBMS-ekkel összehasonlítva?
Számos nézőpontból lehet vizsgálni a szoftvert: képességek, teljesítmény
megbízhatóság, támogatottság és ár.
Képességek
A PostgreSQL rendelkezik a nagy, kereskedelmi DBMS-ek képességeivel:
tranzakciók, al-lekérdezések, triggerek, nézetek, külső kulcsok,
integrítás és kifinoult zármechanizmusok. Van néhány képessége,
ami a kereskedelmi adatbázisokból hiányzik, mint például a
felhasználó által definiált típusok, öröklődés, szabályok és
verzió kontroll a zárolási viták redukálásáért.
Teljesítmény
A PostgreSQL teljesítménye hasonlít a kereskedelmi és más nyílt
adatbázis szerverekéhez. Lehet bizonyos esetekben lassabb, másokban
gyorsabb. A MySQL nevű tanuló RDBMS például gyorsabban hajt végre
insert/update műveleteket, mivel a tranzakciókat elsumákolja.
Persze a MySQL nem rendelkezik a képességek részben felsoroltak
nagy részével. Mi a megbízhatóságra és a képességekre építünk, bár
a teljesítmény is nő minden kiadással. Van egy érdekes oldal a
MySQL és a PostgreSQL összehasonlításával a
http://openacs.org/philosophy/why-not-mysql.html címen.
Megbízhatóság
Tudjuk hogy ha egy DBMS nem megbízható, akkor teljesen haszontalan.
Igyekszünk jól tesztelt, stabil kódot kiadni, amiben a lehető
legkevesebb hiba van. Minden kiadás elött eltellik legalább 1
hónap béta teszt, és a kiadási történet is azt mutatja, hogy
stabil kódot adunk ki, ami készen áll a produktív felhasználásra.
Úgy gondoljuk, felülmúlunk más adatbázis szoftvereket ezen a téren.
Támogatás
A levelezési listáink kapcsolatot teremtenek a fejlesztők
és felhasználók csoportjával , akik segítenek a problémák
megoldásában. Bár nem tudjuk garantálni hogy ki tudjuk
javítani a hibát, más, kereskedelmi adatbázis cégek sem tudják.
A fejlesztő csoport közvetlen elérési lehetősége, a közösség,
a dokumentáció és a forráskód gyakran támogatást biztosít,
mint más adatbázisoknál. Van kereskedelmi, alkalmi támogatás
azoknak, akiknek szüksége van rá (lásd: 1.6).
Ár
A PostgreSQL szabad bármilyen felhasználásra, akár kereskedelmire
is. A termékhez hozzáadhatod a saját forráskódjaidat korlátozás
nélkül,
1.15) Hogyan tudom üzletileg segiteni a PostgreSQL-t?
A PostgreSQL első osztályú infrastruktúrával rendelkezik, amit 1996-ban
indítottunk el. Mindent Marc Fourniernek köszönhetünk, aki létrehozta
és karbantartja a rendszert.
A minőségi infrastruktúra nagyon fontos egy nyilt forrású szoftver
esetében. Megvéd az olyan fennakadásoktól, amelyek komoly késéseket
okoznak a fejlesztésekben.
Természetesen ez az infrastruktúra nem olcsó. Számos havi és állandó
kiadásunk van. Ha a cégednek van pénze, amivel támogatná erőfeszítéseinket,
kérlek látogass el a http://store.pgsql.com/shopping/ oldalra.
Bár a weboldal "PostgreSQL, Inc"-ként említi, a hozzájárulások kizárólag
a PostgreSQL fejlesztésre értendóek, és nem egy meghatározott cégnek. Ha
jobban tetszik, küldhetsz csekket is a kapcsolati címek bármelyikére.
_________________________________________________________________
Felhasználói kliens kérdések
2.1) Van ODBC meghajtó PostgreSQL-hez?
Két ODBC meghajtó érhető el: PsqlODBC és a OpenLink ODBC.
A PsqlODBC a PostgreSQL kiadás része. További információ található a
ftp://ftp.PostgreSQL.org/pub/odbc/ oldalon.
Az OpenLink ODBC-t a http://www.openlinksw.com címről töltheted le.
Ez az ő szabványos ODBC kliens szoftverükkel működik, így minden
általuk támogatott platformon (Win, Mac, Unix, VMS) elérhető lesz
a PostgreSQL szerver.
Talán olyan vevőknek fogják eladni, akik kereskedelmi minőségű terméket
szeretnének kapni, de a freeware verzió mindig elérhető lesz. Kérdéseidet
a termékkel kapcsolatban a postgres95@openlink.co.uk címen teheted fel.
Olvasd el az ODBC fejezetet is a programozók kézikönyvében!
2.2) Milyen eszközök állnak rendelkezésre PostgreSQL Web fejlesztésekhez?
Egy szép bemutató olvasható az adatbázissal támogatott web oldalanról
a http://www.webreview.com weboldalon.
A web integrációhoz a PHP egy kiválló szoftver. Letölthető a
http://www.php.net címről.
Komplexebb esetekre sokan használják a Perl felületet és a CGI.pm vagy a
mod_perl-t.
2.3) Van a PostgreSQL-hez grafikus felhasználói felület? Riport
generátor? Beágyazott lekérdező nyelv felület?
Van egy szép PgAccess nevű grafikus felületünk, ami riport generátorként
is használható. A weboldalát megtalálod a http://www.pgaccess.org/ címen.
A disztribúció tartalmazza az ecpg programot is, ami egy beágyazott SQL
lekérdezési felület C nyelvhez.
2.4) Milyen programozási nyelvekkel lehet elérni a PostgreSQL szervert?
A következök:
* C (libpq)
* C++ (libpq++)
* Embedded C (ecpg)
* Java (jdbc)
* Perl (DBD::Pg and perl5)
* ODBC (odbc)
* Python (PyGreSQL)
* TCL (libpgtcl)
* C Easy API (libpgeasy)
* PHP ('pg_' functions, Pear::DB)
További programozási felületek érhetőek el a
http://www.PostgreSQL.org/interfaces.html és a
http://gborg.PostgreSQL.org oldalakon.
_________________________________________________________________
Adminisztrációs kérdések
3.1) Hogyan tudom a PostgreSQL-t /usr/local/pgsql -től eltérő helyre
installálni?
A configure script --prefix paraméterének használatával.
3.2) AMikor elindítom a postmaster-t, egy "Bad System Call"-t vagy core
dump-ot kapok.
Miért?
Számos probléma lehet, de legelösször ellenőrizd le, hogy a kerneled
System V kiegészítésekkel rendelkezik-e. A PostgreSQL használja a
kernel osztott memória és szemafor API-ját.
3.3) Amikor megpróbálom inditani a postmaster-t, "IpcMemoryCreate" hibákat
kapok. Miért?
Vagy nincs megfelelően konfigurálva a kerneled osztott memória támogatása
vagy meg kell nagyobbítanod a maximális osztott memória méretet.
A pontos méret szükséglet függ az architektúrádtól és attól hogy hány
buffert és processzt konfigurálsz a postmasternek. Legalább 1 MB
területre szükséged van. A PostgreSQL Adminisztráció kézikönyvben
olvashatsz részletesebb információkat az osztott memóriáról és a
szemaforokról.
3.4) Amikor megpróbálom inditani a postmaster-t, "IpcSemaphoreCreate"
hibákat kapok. Miért?
Ha a hibaüzenet ez: " IpcSemaphoreCreate: semget failed (No space
left on device)", akkor a kerneled konfigurációja nem tesz lehetővé
elegendő szemafort. A PostgreSQL szerver processzenként 1 szemafort
igényel. Egy átmeneti megoldás lehet az hogy a postmastert kevesebb
maximális processz számmal inditod el. Használd a -D paramétert.
Egy sokkal megfelelőbb megoldás az ha növeled a kerneled SEMMNS
és SEMMNI paramétereit.
A hibás szemaforok is adatázis lerobbanásához is vezethet nagy terhelés
esetén.
Ha a hibaüzenet valami más, lehet hogy nincs szemaforok támogatás
forditva a kerneledbe. Olvasd el a PostgreSQL adminisztrátorok
kézikönyvében az osztott memóriáról és a szemaforokról szóló fejezetet.
3.5) Hogyan tudom kontrollálni a más gépekről érkező kapcsolat kéréseket?
Alapértelmezésben a PostgreSQL a helyi kapcsolatokat Unix socketekkel
valósítja meg. Más gépek nem lesznek képesek csatlakozni, ha nem
engedélyezed azt -i opcióval a postmasternek, és nem állítod be host a
alapú azonosítást a pg_hba.conf állományban. Ezzel válnak lehetővé a TCP/IP
kapcsolatok.
3.6) Hogyan tudom nagyobb teljesítményre hangolni az adatbázisomat?
Az indexelés feltétlenül gyorsítja a lekérdezéseket. Az EXPLAIN
parancs lehetővé teszi hogy lásd, hogy a PostgreSQL miként interpretálja
a lekérdezést és melyik indexet használja.
Ha sok INSERT műveletet hajtassz végre, csináld nagy kötegekben a COPY
paranccsal. Ez sokkal gyorsabb mint az egyedi INSERT parancsok. Másodszor:
Azok a műveletek, amelyek nincsenek tranzakció blokkon belül, azok saját
tranzakciót indítanak. Sok műveletet érdemes egy tranzakción belül
végrehajtani. Ez csökkenti a tranzakció kezelés többletidejét. Az indexeket
javasolt a nagy adatváltozások elött eltávolítani, majd újra létrehizni.
Számos teljesítmény javító lehetőség van. Kikapcsolhatod az fsync()
műveletet a postmaster -o -F opciókval való indításakor. Így nem fog
az amugy lassú fsync() függvény meghívódni minden tranzakció végén.
Használhatod a postmaster -B opcióját is az osztott memória szegmens
méretének növeléséhez. Ha az értéket túl magasra állítod, lehet hogy
a postmaster nem indul el, mert túllépted az operációs rendszer által
megengedett méretet. Minden buffer 8K méretű és alapértelmezésban 64
buffer van.
A -S opcióval növelheted a szerver átmeneti rendezésekre fenntartott
memória területét. Az értéket kilobyteban add meg. Az alapértelmezett
érték 512K.
Használhatod a CLUSTER utasítást is, hogy a táblákat egy indexnek
megfelelően csoportosítsd. Olvasd el a CLUSTER kézikönyv oldalt további
részletekért.
3.7) Milyen hibakereső lehetőségek érhetőek el?
A PostgreSQL számos lehetöséggel rendelkezik ami értékes lehet a hiba-
keresésnél.
Elösször is, futtathatod a configure scriptet --enable-cassert
opcióval, sok assert() funkcióhivás ellenörzi a program futását és
megállitja ha valami vératlan hiba történik.
Mind a postmaster és a postgres számos hibakeresö lehetüséggel rendelkezik.
Mindig amikor elinditod a postmastert, gyözödj meg róla, hogy a kimenetet
log állományba küldöd. Igy:
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
Ez egy server.log állományt hoz létre a felsö PostgreSQL könyvtárban.
Ez az állomány tartlamaz majd számos hasznos információt a szerverrel
kapcsolatos problémákról és hibákról. A postmaster -d opciójával lehet
részletesebb hibakeresö információt kapni. A -d opcióhoz meg kell
határozni egy hiba szintet. Vigyázz, a magas hibakeresö szint nagy
log állományt okozhat.
Ha a postmaster nem fut, akkor futtathatod a postgres szervert
parancssorból is, és az SQL kifejezést közvetlenül ennek adhatod át.
Ez csak hibakeresés esetében javasolt. Az új sor a kifejezés végét jelenti,
nem a pontosvesszö. Ha hibakeresö opciókkal forditottad a szervert,
használhatsz egy debuggert is hogy lásd hogy mi történik. Mivel igy a
szervert nem a postmaster inditotta, nem többfelhasználós környezetként
fut, igy a zárolási és a szerverek közötti kommunikációs hiba jelenségek
nem jelentkeznek.
Ha már fut a postmaster, indits egy psql-t, és nézd meg a szerver processz
PID-jét! Egy debuggert használhatsz a processzhez csatlakozáshoz.
Beállithatsz töréspontokat és elindithatsz lekérdezéseket. Ha a postgres
inditásban keresel hibát, a PGOPTIONS környezeti változót állitsd be "-W n"
értékre. Ez n másodperc várakozást idéz elö, igy tudsz csatlakozni a
processzhez, el tdsz hejezni töréspontokat, majd folytathatod a indítást.
A postgres program -s, -A és -t opciói is nagyon hasznosak lehetnek
hibakeresésnél és teljesítmény mérésnél.
Profiling lehtöséggel is fordithatod a szervert, hogy lásd melyik
funkciók foglalják el a futási időt. A szerver profile állományai
a pgsql/data/base/dbname könzvtárba kerülnek, a kliens profile
állományok az aktuális könyvtárba. Linuxon ehhez szükséges a
-DLINUX_PROFILE fordítási direktiva.
3.8) Miért kapok "Sorry, too many clients" (Túl sok kliens)
hibát csatlakozásnál?
Növelned kell a postmaster egyidejűleg futtatott szerver processz szám
korlátját.
Az alapértelmezett korlát 32 processz. Ezt növelhetjed úgy, hogy
újrainditod a postmastert és -N opcióval meghatárotod az új értéket,
vagy módositod a postgresql.conf-ot.
Ne felejtsd el, hogy ha növeled a szerver processzek maximális számát,
akkor bufferek számát is növelned kell, legalább a processzek számának
kétszeresére. Nagy processz számokesetében valószinüleg a Unix
konfigurációs paramétereken is növelni kell. Ellenörizd a SHMMAX
(az osztott memória szegmensek maximális mérete), a SEMMNS és a SEMMNI
(a szemaforok maximális száma), az NPROC (a processzek maximális száma),
a MAXUPRC (felhasználónkénti maximális processz szám) és a NFILE és NINODE
(a megnzitott állománzok maximális száma) paramétereket. A PostgreSQL
azért korlátozza külön a processz számot, hogy a rendszeredet ne terhelhesse
meg túlságosan.
A PostgreSQL 6.5 verzióban a maximális szerver processz szám 64 volt és
a módositáshoz bele kellett irni a include/storage/sinvaladt.h állományba
és újra kellett forditani a servert.
3.9) Mi van pgsql_tmp könyvtárban?
Ez a könyvtár a lekérdezés végrehajtó által létrehezott átmeneti
állományokat tartalmazza. Például ha egy rendezést kell végrehajtani
egy ORDER BY kifejezés miatt és a m?velet több memóriát vesz
igénybe, mint amennyit a -S paraméter megenged, akkor az átmeneti
könyvtárban hoz létre egy állományt a fennmaradó adat tárolására.
Az átmeneti állományok többnyire törl?dnek, de meg is maradhat ha
például váratlan hibával leáll a szerver egy rendezés közben. Inditáskor
és leállitáskor ezeket az állományokat törli a postmaster.
3.10) Miért kell dumpolni és újratölteni PostgreSQL kiadás váltásánál?
A PostgreSQL csapat csak apróbb változtatásokat hajt végre a kisebb
kiadások között, igy ha 7.2 verzióról állsz át 7.2.1 verzióra, akkor nem
szükséges kidumplonod az adatbázist. A nagy kiadások esetében (például
verzióról 7.3-ra áttérésnél) változik a belsiő adatstruktúrák és
adatállományok formátuma. Ezek a változások gyakran nagyon összetettek,
ezért inkáb nem tartunk fenn visszafelé kompatibilitást. A dump
az adatot általános formátumban irja ki, majd az új formátumban lehet
azt visszatöleni.
Azokban a kiadásokban, amelyek között az adat formátum nem változik,
a pg_upgrade program használható dumpolás és helzreállitás nélkül.
_________________________________________________________________
Működtetési kérdések
4.1) Mi a különbség a bináris és a normál kurzorok között?
Nézd meg a DECLARE dokumentációját.
4.2) Hogyan tudom select-elni a lekérdezés első pár sorát?
Olvasd el a FETCH dokumentációját, vagy használd a SELECT
LIMIT-et.
Az egész lekérdezést végre kell hajtani, még akkor is, ha csak az első
pár sort akarod megkapni. Gondolj arra, hogy a lekérdezésben lehet ORDER BY
is. Ha van olyan index, ami megfelel az ORDER BY kifejezésednek, a
PostgreSQL képes lehet az elsö néhány rekord visszaadására, vagy a teljes
lekérdezésnek le kell futnia, amig a kért rekordok le nem generálódnak.
4.3) Hogy tudom kilistázni a táblákat vagy más dolgokat a PostgreSQL-ben?
Elolvashatod a psql forrás kódjában a pgsql/src/bin/psql/describe.c
állományban. Ez SQL parancsokat tartalmaz, amelyek azokat a kimeneteket
állitják elö, amiket a per jellel kezdödö parancsok adnak vissza.
4.4) Hogyan tudok eltávolítani egy oszlopot egy táblából?
Ez a funkcionalitás a 7.3 verziótül kezdve érhetö el az ALTER TABLE
DROP COLUMN -nal. A régebbi vertiókban igy lehet végrehajtani:
BEGIN;
LOCK TABLE old_table;
SELECT ... -- minden oszlopot, kivétel amit törölni szeretnél
INTO TABLE new_table
FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
COMMIT;
4.5) Mi a maximális mérete egy sornak, egy táblának vagy egy adatbázisnak?
A korlátok:
adatbázis: korlátlan (1 TB az általunk ismert lagnagyobb)
tábla: 16 TB
rekord/sor 1.6TB
mezö 1 GB
a tábla sorainak száma: korlátlan
a tábla oszlopainak száma: 250-1600 az oszlop nevektől függöen
A tábla indexeinek száma: korlátlan
Természetesen nem igazán korlátlan, de a tárterület, memória és egyéb
külsö tényezök korlátozzák. A teljesitmény romolhat, ha ezek az értékek
szokatlanul nagyok.
A 16 TB-os legnagyobb tábla méret nem igényel nagy állomány támogatást.
A nagy táblák több 1 GB méretü állományba kerölnek, igy az állomány
rendszer korlátai nem lényegesek.
A maximális tábla méret és az oszlopok maximális oszlop szám növelhetö,
ha az alapértelmezett blokkméretet 32k-ra növeled.
4.6) Mekkora adatbázis lemez terület szükséges egy tipikus szöveg állomány
tárolásához?
A PostgreSQL akár a szöveg állomány helyigénzének ötszörösét is elfoglalhaja.
Képzelj el például, egy 100.000 soros szöveget, aminek minde sora
egy számból és egy szövegből áll. Tegyük el, hogy átlagosan 20 byte hosszú
szövegek. Ez a szövegállomány körülbelül 2.8 MB helyet foglalna el.
A tábla ami a fenti adatszerkezetet eltárolná, körülbelül 6.4 MB-os lenne.
Ezt a következöképpen számolhatjuk ki:
36 byte: sor fejléc
24 byte: egy int mezö + egy szöveg mezö
4 byte: mutato
---------------------------------------
64 byte soronkent.
Az adat oldal mérete a PostgreSQL-ben 8192 byte, igy
8192 / 64 = 128 rekord adatbázis oldalanként (lefelé kerekitve).
100000 rekord / 128 rekord oldalanként = 782 adat oldal (felelé kerekitve).
782 adatbázis oldal * 8192 byte olalanként = 6,406,144 byte (6.4 MB)
Az indexek nem foglalnak túl sokat, de tartalmazzák az indexelt adatot,
igy ezek is lehetnek nagyok.
A NULL értékek bittérképben vannak tárolva, igy kevés helyet foglanak.
4.7) Hogy tudhatom meg milyen táblák, indexek, adatbázisok vagy felhasználók
vannak definiálva?
A psql-ben találsz számos '\' karakterrel kezdödö utasítást az ilyen
információk listázására. A '\?' segitségével tudot kilistázni ezeket
a parancsokat. Ezen kivül vannak rendszer táblák, amelyek nevei 'pg_'
-vel kezdödnek.
Próbáld ki a pgsql/src/tutorial/syscat.source állományt is. Ez sok
példát tartalmaz az rendszertáblákon végrehajtott SELECT-ekröl.
4.8) A lekérdezéseim lassúak, vagy nem használják az indexeket. Miért?
Az indexeket nem használja a szerver minden lekérdezésnél automatikusan.
Csak akkor használ indexet, ha a tábla mérete egy megadott alsó határ
felett van, és a lekérdezés csak a sorok egy kis részét érinti. Ez azért
van, mert a véletlen hozzáférés még mindig lassabb lehet mint az tábla
szekvenciális olvasása.
Hogy a PostgreSQL meg tudja határozni hogy kell-e indexet használni,
léteznie kell egy statisztikának a tábláról. Ez a statisztikai adatok a
VAACUM ANALYZE vagy az egyszerű ANALYZE műveletek során
jönnek létre. A statisztikai adatok felhasználásával az optimalizáló
meg tudja határozni, hogy hány sor van a táblában, és el tudja dönteni,
hogy használjon-e indexet. A statisztiaki adatgyüjtést időnként végre
kell hajtani, ahogy a tábla adatai változnak.
Az indexeket normális esetben nem használja az ORDER BY vagy
az OUTER JOIN. A szekvenciális olvasás általában gyorsabb, mint az
index keresés egy nagy táblában.
Bár a LIMIT az ORDER BY-val kombinálva használhat indexet, mert
a tábla csak kis része érintett. Bár a MIN és MAX SQL funkciók sem
használják az indexeket, ezeket az értékeket egy ORDER BY + LIMIT
lekérdezéssel is le lehet kérdezni:
SELECT col
FROM tab
ORDER BY col [ DESC ]
LIMIT 1;
Amikor helyettesítő jel operátorokat használsz, mint a LIKE kulcsszó
vagy a ~, az indexeket csak bizonyos körülmények között lehet használni:
* A kereső string kezdete a keresési minta elején kell hogy legyen.
például:
+ A LIKE minták nem kezdődhetnek % jellel.
+ ~ (regexp) kifejezések nem kezdődhetnek ^ jellel.
* A keresési kifejezés nem kezdődhet karakter osztállyal.
* A case-insensitive keresés (ILIKE, ~*) nem használnak indexet
ehelyett funkcionális indexet használnak, amit a 4.12 pontban
találhatsz.
* Az alapértelmezett C hellyel kell futtatni az initdb-t.
4.9) Hogy tudom ellenőrizni, hogy optimalizálta a lekérdezés optimalizáló
a lekérdezésem?
Olvasd el a dokumentáció EXPLAIN-ról szóló részét.
4.10) Mi az R-tree index?
Az R-tree index a térbeli adat indexelésére alkalmas. Egy hash
index nem képes tartomány keresésekre. A B-tree index csak egy
dimenzión kezeli a tartomány kereséseket. Például ha az indexet
egy pont (point adattípus) típusú mez.re építjük, gyorsabban
kezeli az olyan jellegü lekérdezéseket, mint egy adott körben
található pontok.
Az R-tree tervezési mintát eredetileg leíró szöveg:
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.
Ezt olvashatod Stonebraker "Readings in Database Systems" c.
könyvében.
A beépített R-tree kezelni tudják a sokszögeket (polygon adattípus)
és a dobozokat (box). Elméletileg, az R-tree kiterjeszthető további
dimenziókra is. Gyakorlatilag ezen dolgoznod kell egy kicsit, és
még nincs dokumentációnk arról hogy az hogyan működik.
4.11) Mi a Genetic Query Optimizer?
A GEQO modul a lekérdezés optimalizáció sebességét növeli nagy
mennyiségű tábla összekapcsolása esetén. Lehetővé teszi a nagy
lekérdezések végrehajtását nem teljes kereséssel.
4.12) Hogyan tudok regexp keresést és case-insensitive regexp keresést
használni? Hogyan tudok indexet használni case-insensitive kereséshez?
A ~ operátor hajt végre reguláris kifejezés (regexp) értelmezést,
a ~* ennek case-insensitive változata. A LIKE case-insensitive
változata az ILIKE.
A case-insensitive egyenlőség műveleteket általában igy hajtjuk
végre:
SELECT *
FROM tab
WHERE lower(col) = 'abc';
Ez nem fog indexet használni, bár létrehozhatsz egy funkció indexet:
CREATE INDEX tabindex ON tab (lower(col));
4.13) Hogyan tudom észlelni egy lekérdezésben, ha egy mező NULL?
Használd "IS NULL"-t és az "IS NOT NULL"-t.
4.14) Mi a különbség a különböző karaktertípusok között?
Type Internal Name Notes
--------------------------------------------------
"char" char 1 character
CHAR(n) bpchar blank padded to the specified fixed length
VARCHAR(n) varchar size specifies maximum length, no padding
TEXT text no specific upper limit on length
BYTEA bytea variable-length byte array (null-byte safe)
Látni fogod a belső elnevezésüket, ha tanulmányozod a rendszertáblákat
és néhány hibaüzenetet.
Az utóbbi négy a "varlena" típusok, ami a tárolásuk módjára utal:
az első 4 byte a lemezen a hosszúság, a többi az adat. A valódi méret
tehát nagyobb mint a deklarált hosszúság.Ezek azadatok tömöritve
tárolódnak el, igy kevesebb helyet foglalnek el az elöre számitottnál.
A CHAR(n) a legjobb megoldás, ha stabil hosszúságú stringet tárolsz.
A VARCHAR(n) jó arra az esetekre, ha a hosszúság változik, de van
felső korlátja. A TEXT típus korlátlan hosszúságú (1 GB-ig) szövegek
tárolására alklamas. A BYTEA bináris adatok tárolására van. A
teljesitmény mutatói hasonlóak ezenek a típusoknak.
4.15.1) Hogyan tudok létrehozni automatikusan növekvő értékű mezőt?
A PostgreSQL rendelkezik egy SERIAL adattípussal. Ez egy szekvenciát
és egy indexet hoz létre az oszlopon. Például ez:
CREATE TABLE person (
id SERIAL,
name TEXT
);
ugyanezt jelenti:
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 );
A szekvenciákkal kapcsolatban olvasd el a create_sequence man
oldalt. A sor OID-jét is használhatod egyedi azonositóként, bár
ebben az esetben figyelj a pg_gump használatánál a -o opcióra
(COPY WITH OIDS, másolás OID-dal), hogy meg?rizd az értékeket.
4.15.2) Hogyan kaphatom meg egy SERIAL beszúrás értékét?
Egy megoldás erre az, ha a nextval() funkcióval megszerzed az
értéket még mielött beszúrnád az adatot a táblába. Erre itt láthatsz
egy példát:
new_id = execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
Esetleg lekérdezheted a szekvencia állapotát a sor beszúrása után.
execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
new_id = execute("SELECT currval('person_id_seq')");
Végül pedig, használhatod a visszaadott OID értéket is, bár ez a lehető
legkevésbé portolható. Perl DBI-ben, Edmund Mergl DBD::Pg moduljában
az OID érték használható a $sth->execute() után ($sth->{pg_oid_status}).
4.15.3) A currval() és a nextval() nem teremt holtpont veszélyes helyzetet
a felhasználók között?
Nem. A currval() funkció a szerver processzed által adott értéket adja
vissza, nem pedig a többi szerver processz által adottat.
4.15.4) Miért nem használódnak fel újra a sequence számok tranzakció
abort esetén?
Miért vannak problémák a serial oszlopok számozásával?
A párhuzamosság fejlesztése érdekében a sorozat számokat kérésre
adja ki a szerver futó tranzakcióknak, és azokat nem zárja, amig
a tranzakció véget nem ér. Ez jukakat okoz a számozásokban a
visszaforditott tranzakciók miatt.
4.16) Mi a OID? Mi a TID?
Az OID a PostgreSQL egyedi sor azonositója. Minden sor, ami létrejön
a szerveren, kap egy OID-t. Minden OID, amit az initdb alatt jön létre
16384 alatt van (lásd include/access/transam.h). Minden, felhasználó
által létrehozott OID legalább ennyi. Alapértelmezésben, az OID
nem csak a táblában vagy az adatbázisban egyedi, hanem a teljes
PostgreSQL adatbázis rendszerben.
A PostgreSQL az OID-okat a belsö tábláiban használja a sorok táblák
között összekapcsolásához. Ezek az OID-k használhatóak a rekordok
azonositására is amikor táblákat csatol össze a szerver (JOIN).
Az OID-ot használhatod mezö típusként is, és indexelheted is.
Az OID érték egy központi területröl származik, amit minden szerver
processz használ. Ha az OID-ot valami másra szeretnéd cserélni:
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';
Az OID 4 byte-os integer értékként tárolódik, igy 4 milliárdnál túlcsordul.
Még soha senki nem jelezte hogy ez történt volna, és ezt a korlátot
igyekszünk eltávolitani, még mielött bárki észrevenné.
A TID a fizikai sorok blokk és offszet címmel való azonositására szolgál.
A TID változik minden rekord módositás és törlés alkalmával. Ezeket az
indexek használják hogy a fizikai sort gyorsan megtalálják.
4.17) Mi a PostgreSQL-ben használt kifejezések jelentése?
Néhol a forrás kódban és a dokumnetációban találhatóak kifejezések,
amelyek általánosabb jelentéssel bírnak. Itt van néhány:
* tábla (table), reláció (relation), osztály (class)
* sor (row), rekord (record), tuple (nincs magyar jelentés)
* oszlop (column), mezö (field), attributum (attribute)
* retrieve, select
* helyettesit (replace), módosit (update)
* hozzáfűz (append), beszúr (insert)
* OID, sorozat érték (serial value)
* portal, cursor
* range variable, tábla név, tábla alias
Az általános adatbázis kifejezések összefoglalóját itt olvasható:
http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
/glossary.html
4.18) Miért kapom ezt a hibát: "ERROR: Memory exhausted in
AllocSetAlloc()"?
Lehet hogy elfogyott a virtuális memóriád, vagy a kerneled erőforrás
korlátai alacsonyak. Próbáld ki ezt mielött elinditanád a postmastert:
ulimit -d 262144
limit datasize 256m
A shelltől függően ezek közül csak az egyik fut majd le, de a
processzek adatszegmensét sokkal magasabbra állitja, ami talán
elég lesz a lekérdezés végrehajtásához. Ez az utasítás a jelenlegi
processzre (a shelled) érvényes, és minden általa létrehozott
processzre. Ha problémád van az SQL klienssel, mert a szerver
túl nagy adatot küld vissza, próbáld meg e klienssel is ugyanezt.
4.19) Hogyan tudhatom meg PostgreSQL, milyen verziót futtatok?
A psql programban select version();
4.20) Miért kapok "invalid large obj descriptor" hibát nagy objektumok
kezelésénél?
A nagy objektumok kezelését egy tranzakciós blokkban helyezd el.
(BEGIN és COMMIT között)
Jelenleg a PostgreSQL ezt a szabályt azzal teszi kötelezővé, hogy a
tranzakció végén a nagy objektumokat lezárja, igy a tranzakció után
az első művelet amit az objektumon végrahajtanál hibás lesz.
Ha olyan programozási felületet használsz mint az ODBC vagy a JDBC
akkor valószinűleg ki kell kapcsolnod az auto-commit-ot.
4.21) Hogy hozhatok létre olyan oszlopot, aminek alapértelmezett
érétke a jelenlegi idő?
Használd a CURRENT_TIMESTAMP -ot:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
4.22) Miért olyan lassúak az al-lekérdezéseim IN-nel?
Jelenleg az al-lekérdezéseket a külső lekérdezéshez csatoljuk. Ha
az allekérdezés csak kevés sort eredményez és a külső lekérdezés
sokat, akkor az IN is gyors. Az EXISTS kulcsszó használatával
gyorsithatod a lekérdezéseket.
SELECT *
FROM tab
WHERE col IN (SELECT subcol FROM subtab);
EXISTS használatával:
SELECT *
FROM tab
WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);
Ahhoz hogy ez gyorsan fusson le, a subcol indexelt oszlopnak kell
hogy legyen. Reméljük ezt a korlátot sikerül hamarosan legyőznünk.
4.23) Hogyan tudok outer join-t végrehajtani?
A PostgreSQL a szabványos SQL szintaktikát követi. Itt van két példa:
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
vagy
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
Ezek az identikus lekérdezések összekapcsolják a t1.col és a t2.col
mezőket, és a t1 bármelyik kapcsolatlan sorát is visszadják. A RIGHT
JOIN a t2 kapcsolatlan sorait adta volna vissza, a FULL JOIN pedig
a kapcsolt, és mindkét tábla kapcsolatlan sorait adja. Az OUTER
kulcsszó opcionális, a LEFT, RIGHT és FULL JOIN szintaktikailag
helyes. Az átlagos összekapcsolásokat INNER JOIN-nak nevezzük.
Az előző kiadásokban a OUTER JOIN lekérdezéseket UNION és NOT IN
kulcsszavakkal lehetett szimulálni. Például a tab1 és a tab2
összekapcsolása:
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) Hogyan tudok több adatbázison végrehajtani lekérdezést?
Arra nincs lehetőség, hogy más adatbázisból kérdezz le adatot.
Mivel a PostgreSQL adatbázis specifikus rendszer táblákat tölt
be, bizonytalan hogy egy adatbázisok közötti lekérdezésnek hogyan
kellene viselkednie.
A contrib/dblink könyvtárban találsz egy megoldást erre, ami
funkció hivások segitségével működik. Persze, a kliens hozhat létre
szimultán kapcsolatot több adatbázissal, és összefésülheti az
eredményeket.
4.25) Hogy tudok több soros vagy oszlopos eredményt visszaadni egy
funkcióból?
A PL/pgSQL tárolt eljárás nyelvvel refcursor használatával.
Részletesen itt:
http://www.PostgreSQL.org/idocs/index.php?plpgsql-cursors.html
4.26) Miért nem tudom megbizhatóan létrehozni és törölni az átmeneti
táblákat a PL/pgSQL funkciókban?
A PL/pgSQL cacheli a funkciók tartalmát, aminek az a szerencsétlen
mellékhatása, hogy ha egy PL/pgSQL funkció használ egy átmeneti
táblát, ami kés?bb törlődik majd ujra létrejön, akkor az újra lefutó
funkció nem fogja megtalálni a táblát, mert a cache változat a régi
táblára tartalmaz mutatót. A megoldás erre az EXECUTE utasítás
használata az átmeneti táblák kezelésére PL/pgSQL-ben. Ez a
lekérdezés újrafordítását fogja előidézni minden alkalommal.
4.27) Milyen replikációs lehetőségek vannak?
Számos master/slave replikációs lehetőség létezik. Ez csak a master
adatbázis számára teszi lehetővé, hogy az adatokat változtassa. Egy
Listát olvashatsz ezekről itt:
http://gborg.PostgreSQL.org/genpage?replication_research
Egy többfelhasználós replikációs rendszer készül itt:
http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
4.28) Milyen kódolási lehetőségek vannak?
- A contrib/pgcrypto tartlamaz számos SQL lekérdezésben használható kódolást.
- A kliens-szerver kommunikáció rejtjelezésére a hostssl használható.
Ezt a pg_hba.conf-ben engedélyeztheted.
- Az adatbázis felhsználók jelszavait tároláskor kódolja a rendszer.
Régebbi verziókban a PASSWORD_ENCRYPTION opcióval lehetett
bekapcsolni.
- A szerveren használhatsz kódolt fájrendszert.
_________________________________________________________________
A PostgreSQL kiterjesztése
5.1) Írtam egy felhasználói funkciót. Miért core dumpol az adatbázis amikor
használom?
Számos probléma lehet. Elöbb probáld ki a funkciódat egy különálló
alkalmazásban.
5.2) Hogyan lehet új adattípusokat és funkciókat hozzáadni a PostgreSQL
disztribúcióhoz?
Küldd el a kiegészítéseid a pgsql-hackers levelezési listára és a
forráskodjaid végül a contrib-ban kötnek ki.
5.3) Hogyan lehet olyan C funkciót írni, ami Tuple-t ad vissza?
A 7.3 verziótól kezdve a PostgreSQL támogatja a táblázatokat
viszzaadó funkciókat C, PL/pgSQL és SQL nyelveken. Bővebb
dokumentációt a Programozó kézikönyvben találsz. Egy C példa
funkció található a contrib/tablefunc könyvtárban.
5.4) Megváltoztattam egy forrás állományt. Miért nem változik a bináris
újrafordítás után?
A Makefile-ok nem ismerik a include állományok megfelelő függőségeit.
Végre kell hajtanod egy make clean-t, majd újra egy make-t. Ha GCC-t
használsz felhasználhatod a configure script --enable-depend opcióját,
így a compiler maga fogja ellenőrizni a függőségeket.
Reference in New Issue View Git Blame Copy Permalink