1,329c1,366 <
< < < < <PostgreSQL se vyslovuje Post-Gres-Q-L.
< < PostgreSQL vychází z databáze POSTGRES - výzkumného prototypu DBMS < nové generace. Z postgresu byl převzat silný datový model a bohatý < soubor datových typů a jeho dotazovací jazyk PostQuel byl nahrazen < rozšířenou podmnožinou jazyka SQL. PostgreSQL lze používat bez < omezení a jeho zdrojové kódy jsou volně k dispozici. < <PostgreSQL vyvýjí tým vývojářů přihlášených do vývojářské konference < PostgreSQL. Současným koordinátorem je Marc G. Fournier. (Odpověď < 1.6. - jak se zapojit). Tento tým je zodpovědný za veškerý vývoj < PostgreSQL.
< <Autory první verze PostgreSQL 1.01 byli Andrew Yu and Jolly < Chen. Do portace, testování, ladění a < rozšiřování kódu se zapojilo mnoho dalších vývojářů . Původni kód Postgresu, ze kterého PostgreSQL < vychází, je výsledkem úsilí mnoha studentů a programátorů pracujících < pod vedením prof. Michaela Stonebrakera na University of California v < Berkley.
< <Původní název software z Berkley byl Postgres. Po přidání jazyka SQL < se název změnil na Postgres95. Koncem roku 1996 byl RDBMS < přejmenován na PostgreSQL.
< <PostgreSQL je předmětem následujících autorských práv:
< <Dílčí copyright (c) 1996-2002, PostgreSQL Global Development Group
< <Dílčí copyright (c) 1994-6, Regents of the University of California
< < <Uděluje se oprávnění k užití, rozmnožování, provádění úprav a < rozšiřování tohoto softwaru a dokumentace k němu, pro jakékoli účely, < bez licenčního poplatku a bez písemné licenční smlouvy, za podmínky, že < na všech jeho kopiích je uvedeno oznámení o výše uvedených právech, < jakož i obsah tohoto a dvou následujících odstavců.
< < <THE UNIVERSITY OF CALIFORNIA ("KALIFORNSKÁ UNIVERZITA") NENÍ V ŽÁDNÉM < PŘÍPADĚ ODPOVĚDNA ŽÁDNÉ TŘETÍ OSOBĚ ZA PŘÍMOU, NEPŘÍMOU, ZVLÁŠTNÍ, < NAHODILOU NEBO VýSLEDNOU ŠKODU, VČETNĚ UŠLÉHO ZISKU, ZPůSOBENOU UŽITÍM < TOHOTO SOFTWARU A DOKUMENTACE K NĚMU, A TO I V PŘÍPADĚ, ŽE THE < UNIVERSITY OF CALIFORNIA BYLA INFORMOVÁNA O MOŽNOSTI VZNIKU TAKOVÉ ŠKODY.
< < <THE UNIVERSITY OF CALIFORNIA ZEJMÉNA NEPOSKYTUJE JAKÉKOLI ZÁRUKY, A TO < NEJEN ZÁRUKY OBCHODOVATELNOSTI A VHODNOSTI TOHOTO VýROBKU KE SPECIFICKýM < ÚČELůM. NÍŽE UVEDENý SOFTWARE JE POSKYTNUT "JAK STOJÍ A LEŽÍ" A THE < UNIVERSITY OF CALIFORNIA NENÍ POVINNA ZAJISTIT JEHO ÚDRŽBU, PODPORU, < AKTUALIZACI, VYLEPŠENÍ NEBO MODIFIKACI.
< <Výše uvedené je BSD licence, běžná licence otevřeného zdroje. Není zde < žádné omezení ohledně užití kódu zdroje. Jsme s tím spokojeni a nemáme v < úmyslu na této skutečnosti cokoli měnit.
< < <PostgreSQL běží na všech moderních unixových platformách. V instalačních < instrukcích naleznete aktuální seznam všech platforem na kterých byla < testováním ověřena funkcionalita PostgreSQL.
< <Knihovna libpq, psql a některé další moduly byly přeloženy pro < MS Windows. Klienta lze provozovat na MS Windows, ten prostřednictvím < TCP/IP protokolu komunikuje se serverem běžícím na některé z podporovaných < Unixových platforem. K překladu lze použít win32.mak a < Win32 knihovny libpq a psql. K databázi PostgerSQL lze přistupovat skrze < rozhraní ODBC.
< <Server může být na WindowsNT a Win2k provozován pouze s knihovnou Cygwin, < Cygnus Unix/NT porting library. Na nativním portu pro MS Win NT/2000/XP < se pracuje. Existující port pro Novell Netware 6 naleznete na < http://forge.novell.com.
< <Primárním anonymním ftp serverem pro PostgreSQL je < ftp://ftp.PostgreSQL.org/pub < . Seznam zrcadel naleznete na našich < webových stránkách.
< <
Hlavním mailová konference je pgsql-general@PostgreSQL.org. Slouží < k diskuzím ohledně PostgreSQL. Přihlásíte se zasláním mailu < obsahující následující řádky v těle dopisu (nikoliv v záhlaví - subjectu)
<subscribe < end << na adresu mailto:pgsql-general-request@PostgreSQL.org. < <
Můžete si vyžádat denní přehled (diggest), který má zhruba 30K denně zpráv. < <
Konference psql-bugs je určena k zasílání zpráv o chybách. Pro přihlášení
< pošlete mail se stejným obsahem jako v předchozím případě na adresu
<
Do vývojářské konference se přihlásíte odesláním dopisu s < již zmiňovaným obsahem na mailto:pgsql-hackers-request@PostgreSQL.org.
< <Seznam dalších konferencí naleznete na stránkách PostgreSQL < http://www.postgresql.org
< <Poslední verzí je PostgreSQL 7.4.. Plánujeme uvolnit velkou verzi < každých šest až osm měsíců.
< <Různé manuály, manuálové stránky a několik malých testovacích příkladů < jsou součásti distribuce. Podívejte se do adresáře /doc. Manuály jsou < přístupné online na http://www.PostgreSQL.org/docs.
< <Na adresách http://www.PostgreSQL.org/docs/awbook.html a < http://www.commandprompt.com/ppbook/ naleznezte dvě online knihy o < PostgreSQL. Seznam dostupné literatury je na < http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Soubor < technických článků s tematikou PostgresQL najdete na < http://techdocs.PostgreSQL.org/.
< <psql má užitečný metapříkaz \d sloužící k zobrazení informací < o typech, operátorech, funkcí, agregačních funkcí atd.
< <Více dokumentace naleznete na našich webových stránkách.
< <PostgreSQL podporuje rozšířenou podmnožinu SQL-92. V našem TODO najdete < seznam známých chyb, chybějících vlastností a seznam vlastností, < které budou do systému implementovány v budoucnu (včetně priorit).
< <V knize The PostgreSQL book na http://www.PostgreSQL.org/docs/awbook.html < je vysvětlen jazyk SQL (vyšla česky). Další dostupnou knihou je < http://www.commandprompt.com/ppbook. Kvalitní návody naleznete na < http://www.intermedia.net/support/sql/sqltut.shtm, na < http://www.intermedia.net/support/sql/sqltut.shtm, < a na http://sqlcourse.com.
< <Další je Teach Yourself SQL in 21 days, Second Edition na < http://members.tripod.com/er4ebus/sql/index.htm.
< <Mnoho uživatelů doporučuje The Practical SQL Handbook, Bowman, Judith < S., et al., Addison-Wesley. Jiní preferují The Complete Reference SQL, < Groff et al., McGraw-Hill.
< <Nemá, můžeme pracovat s datumy po roce 2000 našeho letopočtu i před < rokem 2000 př.n.l.
< <Nejdříve si stáhněte nejnovější zdroje a přečtěte si vývojářskou < dokumentaci na našem webu nebo v distribuci. Pak se přihlašte do < konferencí pgsql-hackers a pgsql-patches. Kvalitní záplaty < posílejte do pgsql-patches.
< <Právo commit má v cvs archivu asi třinácti lidí. Každý z nich < poslal mnoho kvalitních záplat, takže tehdejší commiters měli < jistotu, že budou předkládat jenom kvalitní záplaty a mohli jim < předělit větší práva.
< <Navštivte naši PostgreSQL BugTool stránku na < http://www.PostgreSQL.org/bugs/bugs.php, která obsahuje návod a < směrnice jak podat chybový report.
< <Ověřte si na našem ftp serveru ftp://ftp.PostgreSQL.org/pub, zda-li < máte nejnovější verzi PostgreSQL a zda-li k ní neexistují nějaké záplaty.
< <Existuje několik hledisek jak porovnávat software: vlastnosti, výkon, < spolehlivost, podpora a cena.
< <PostgreSQL má hodně společných vlastností s velkými komerčními < DBMS, např. transakce, vnořené dotazy, spouště, pohledy, < kontrolu referenční integrity a sofistikované < zamykání. Podporuje některé vlastnosti, které tyto systémy < nemají, uživatelem definované typy, dědičnost, pravidla, MVCC < redukující zamykání.
< <Výkonnostně je na tom PostgreSQL podobně jako další komerční < ale i open source databáze, v něčem je rychlejší, jindy < pomalejší. V porovnání s MySQL a podobnými databázovými < systémy je PostgreSQL rychlejší při víceuživatelském < přístupu, složitějších dotazech a zatížení read/write dotazy. MySQL < je rychlejší v jednodušších dotazech s malým počtem < uživatelů. Navíc, MySQL nepodporuje mnohé vlatnosti zmíněné v < sekci vlastnosti. Zapracovali jsme na spolehlivosti a podporovaných < vlastnostech, a výkon zvyšujeme v každé < verzi. Zajímavou stránku porovnávající PostgreSQL a MySQL < naleznete na < http://openacs.org/philosophy/why-not-mysql.html. Za vývojem MySQL < není Open Source komunita, ale komerční společnost, přestože < svoje produkty distribuuje jako Open Source.
< <Jsme si vědomi, že databáze musí být spolehlivá, jinak je < nepoužitelná. Snažíme se zveřejňovat dobře otestovaný, stabilní kód s < minimem chyb. Každá verze je více než měsíc v beta testování, < a naše historie verzí ukazuje, že můžeme nabídnout stabilní, < solidní verze, které jsou připraveny pro reálné nasazení. V < této oblasti jsme srovnatelní s dalšími databázemi.
--- > > > > > > > > > >Poslední aktualizace: Středa 23. června 21:10:00 EST 2004
> >Současný správce: Bruce Momjian ( "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us)
> >Přeložil: Pavel Stěhule ( "mailto:stehule@kix.fsv.cvut.cz">stehule@kix.fsv.cvut.cz)
> >Aktuální verzi tohoto dokumentu naleznete na adrese: "http://www.PostgreSQL.org/docs/faqs/FAQ.html">http://www.PostgreSQL.org/docs/faqs/FAQ.html. > Český překlad na adrese: > http://www.PostgreSQL.org/docs/faqs/FAQ_czech.html.
> >Odpovědi na dotazy relevantní ke konkrétním platformám > lze nalézt na adrese: > http://www.PostgreSQL.org/docs/index.html.
>PostgreSQL se vyslovuje Post-Gres-Q-L. Zvukový záznam je > dostupný na adrese .
> >PostgreSQL vychází z databáze POSTGRES (a stále je někdy označován > zjednodušeně jako Postgres) - výzkumného prototypu DBMS nové > generace. Z postgresu byl převzat silný datový model a bohatý soubor > datových typů a jeho dotazovací jazyk PostQuel byl nahrazen rozšířenou > podmnožinou jazyka SQL. PostgreSQL lze používat bez omezení a jeho > zdrojové kódy jsou volně k dispozici.
> >PostgreSQL vyvýjí tým vývojářů přihlášených do vývojářské konference > PostgreSQL. Současným koordinátorem je Marc G. Fournier ( "mailto:scrappy@PostgreSQL.org">scrappy@PostgreSQL.org). > (viz 1.6 - jak se zapojit). Tento tým je zodpovědný za veškerý vývoj > PostgreSQL. Jedná se o veřejný projekt, který není řízen žádnou firmou. > Pokud se chcete zapojit, přečtěte si developer's FAQ na adrese "http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html">http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html
> >Autory první verze PostgreSQL 1.01 byli Andrew Yu and Jolly Chen. Do > portace, testování, ladění a rozšiřování kódu se zapojilo mnoho dalších > vývojářů . Původni kód Postgresu, ze kterého PostgreSQL vychází, je > výsledkem úsilí mnoha studentů a programátorů pracujících pod vedením > prof. Michaela Stonebrakera na University of California v Berkley.
> >Původní název software z Berkley byl Postgres. Po přidání jazyka SQL se > název změnil na Postgres95. Koncem roku 1996 byl RDBMS přejmenován na > PostgreSQL.
> >PostgreSQL je předmětem následujících autorských práv:
> >Dílčí copyright (c) 1996-2004, PostgreSQL Global Development Group > Dílčí copyright (c) 1994-6, Regents of the University of California
> >Uděluje se oprávnění k užití, rozmnožování, provádění úprav a > rozšiřování tohoto softwaru a dokumentace k němu, pro jakékoli účely, > bez licenčního poplatku a bez písemné licenční smlouvy, za podmínky, že > na všech jeho kopiích je uvedeno oznámení o výše uvedených právech, > jakož i obsah tohoto a dvou následujících odstavců.
> >THE UNIVERSITY OF CALIFORNIA ("KALIFORNSKÁ UNIVERZITA") NENÍ V ŽÁDNÉM > PŘÍPADĚ ODPOVĚDNA ŽÁDNÉ TŘETÍ OSOBĚ ZA PŘÍMOU, NEPŘÍMOU, ZVLÁŠTNÍ, > NAHODILOU NEBO VÝSLEDNOU ŠKODU, VČETNĚ UŠLÉHO ZISKU, ZPůSOBENOU UŽITÍM > TOHOTO SOFTWARU A DOKUMENTACE K NĚMU, A TO I V PŘÍPADĚ, ŽE THE > UNIVERSITY OF CALIFORNIA BYLA INFORMOVÁNA O MOŽNOSTI VZNIKU TAKOVÉ > ŠKODY.
> >HE UNIVERSITY OF CALIFORNIA ZEJMÉNA NEPOSKYTUJE JAKÉKOLI ZÁRUKY, A TO > NEJEN ZÁRUKY OBCHODOVATELNOSTI A VHODNOSTI TOHOTO VýROBKU KE SPECIFICKýM > ÚČELůM. NÍŽE UVEDENý SOFTWARE JE POSKYTNUT "JAK STOJÍ A LEŽÍ" A THE > UNIVERSITY OF CALIFORNIA NENÍ POVINNA ZAJISTIT JEHO ÚDRŽBU, PODPORU, > AKTUALIZACI, VYLEPŠENÍ NEBO MODIFIKACI.
> >Výše uvedené je BSD licence, běžná licence otevřeného zdroje. Není zde > žádné omezení ohledně užití kódu zdroje. Jsme s tím spokojeni a nemáme v > úmyslu na této skutečnosti cokoli měnit.
> >PostgreSQL běží na všech moderních unixových platformách. V instalačních > instrukcích naleznete aktuální seznam všech platforem na kterých byla > testováním ověřena funkcionalita PostgreSQL.
> >Klient
> >Knihovna libpq, psql a některé další moduly byly přeloženy pro MS > Windows. Klienta lze provozovat na MS Windows, ten prostřednictvím > TCP/IP protokolu komunikuje se serverem běžícím na některé z > podporovaných Unixových platforem. K překladu lze použít win32.mak a > Win32 knihovny libpq a psql. K databázi PostgerSQL lze přistupovat skrze > rozhraní ODBC.
> >Server
> >
Server může být na WindowsNT a Win2k provozován pouze s knihovnou > Cygwin, Cygnus Unix/NT porting library. Více pgsql/doc/FAQ_MSWIN v > distribuci nebo MS Windows FAQ na adrese > http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN. > >
Na nativním portu pro MS Win NT/2000/XP se pracuje. Další informace > o aktuálním stavu PostgreSQL pro Windows naleznet na adrese > http://techdocs.postgresql.org/guides/Windows a > > http://momjian.postgresql.org/main/writings/pgsql/win32.html. > >
Existující port pro Novell Netware 6 naleznete na > http://forge.novell.com.
> >Primárním anonymním ftp serverem pro PostgreSQL je > ftp://ftp.PostgreSQL.org/pub. > Seznam zrcadel naleznete na našich webových stránkách.
> >Hlavní mailová konference je: > pgsql-general@PostgreSQL.org. Slouží k > diskuzím ohledně PostgreSQL. Přihlásíte se zasláním mailu obsahující > následující řádky v těle dopisu (nikoliv v záhlaví - subjectu):
>> subscribe > end >> na adresu > pgsql-general-request@PostgreSQL.org. > >
Můžete si vyžádat denní přehled (diggest), který má zhruba 30K denně > zpráv.
> >Konference psql-bugs je určena k zasílání zpráv o chybách. Pro > přihlášení pošlete mail se stejným obsahem jako v předchozím případě na > adresu > pgsql-bugs-request@PostgreSQL.org.
> >Do vývojářské konference se přihlásíte odesláním dopisu s již zmiňovaným > obsahem na mailto:pgsql-hackers-request@PostgreSQL.org.
> >Seznam dalších konferencí naleznete na stránkách PostgreSQL:
>> http://www.postgresql.org >>
Poslední verze PostgreSQL je 7.4.3. Plánujeme uvolnit významnou verzi > každých šest až osm měsíců.
> >Různé manuály, manuálové stránky a několik malých testovacích příkladů > jsou součásti distribuce. Podívejte se do adresáře /doc. Manuály jsou > přístupné online na http://www.PostgreSQL.org/docs.
> >Na adresách http://www.PostgreSQL.org/docs/awbook.html a > http://www.commandprompt.com/ppbook/ > naleznezte dvě online knihy o PostgreSQL. Seznam dostupné literatury je na > > http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Soubor > technických článků s tematikou PostgresQL najdete na "http://techdocs.PostgreSQL.org/">http://techdocs.PostgreSQL.org/.
> >psql má užitečný metapříkaz \d sloužící k zobrazení informací o typech, > operátorech, funkcí, agregačních funkcí atd.
> >Více dokumentace naleznete na našich webových stránkách.
> >PostgreSQL podporuje rozšířenou podmnožinu SQL-92. V našem > TODO > najdete seznam známých chyb, chybějících vlastností a seznam vlastností, > které budou do systému implementovány v budoucnu (včetně priorit).
> >V knize The PostgreSQL book na "http://www.PostgreSQL.org/docs/awbook.html"> > http://www.PostgreSQL.org/docs/awbook.html je vysvětlen jazyk SQL (vyšla > česky). Další dostupnou knihou je "http://www.commandprompt.com/ppbook">http://www.commandprompt.com/ppbook. > Kvalitní návody naleznete na "http://www.intermedia.net/support/sql/sqltut.shtm"> > http://www.intermedia.net/support/sql/sqltut.shtm, a na > http://sqlcourse.com.
> >Další je Teach Yourself SQL in 21 days, Second Edition na "http://members.tripod.com/er4ebus/sql/index.htm">http://members.tripod.com/er4ebus/sql/index.htm.
> >Mnoho uživatelů doporučuje The Practical SQL Handbook, Bowman, Judith > S., et al., Addison-Wesley. Jiní preferují The Complete Reference SQL, > Groff et al., McGraw-Hill.
> >Nemá, můžeme pracovat s datumy po roce 2000 našeho letopočtu i před > rokem 2000 př.n.l.
> >Nejdříve si stáhněte nejnovější zdroje a přečtěte si vývojářskou > dokumentaci na našem webu nebo v distribuci. Pak se přihlašte do > konferencí pgsql-hackers a
pgsql-patches. Kvalitní záplaty posílejte do > pgsql-patches.
> >Právo commit má v CVS archivu asi třinácti lidí. Každý z nich poslal > mnoho kvalitních záplat, takže tehdejší commiters měli jistotu, že budou > předkládat jenom kvalitní záplaty a mohli jim předělit větší práva.
> >Navštivte naši PostgreSQL BugTool stránku na "http://www.PostgreSQL.org/bugs/bugs.php">http://www.PostgreSQL.org/bugs/bugs.php, > která obsahuje návod a směrnice jak podat chybový report.
> >Ověřte si na našem ftp serveru ftp://ftp.PostgreSQL.org/pub, > zda-li máte nejnovější verzi PostgreSQL a zda-li k ní neexistují nějaké záplaty.
> >Existuje několik hledisek jak porovnávat software: vlastnosti, výkon, > spolehlivost, podpora a cena.
>Na naší mailové konferenci můžete kontaktovat velkou skupinu --- >
PosgreSQL lze volně používat pro nekomerční i komerční < použití. Můžete do svých produktů přidat náš kód bez omezení, < respektive v souladu s podmínkami naší licenční smlouvy (v duchu BSD < licence).
< <PosgreSQL má prvotřídní infrastrukturu od našeho začátku v roce < 1996. Vděčíme za to Marku Fournierovi, který založil a spravoval tuto < infrastrukturu několik let.
< <Kvalitní infrastruktura je velice důležitá pro každý open source < projekt. Předchází nedorozuměním, která velice zdržují pokrok v projektu.
< <Tato infrastruktura není laciná. K jejímu zajištění je třeba stále hradit určité < měsíční a jednorázové částky. Pokud máte Vy nebo Vaše společnost < peníze, které nám můžete darovat, obraťe se na http://store.pgsql.com/shopping/ a darujte je.
< <Ačkoliv webová stránka zmiňuje PostgreSQL, Inc. vklady jsou určeny < pouze k podpoře projektu PostgreSQL a nepodporují žádnou existující < společnost. Pokud to vyžadujete, můžete poslat kontrolu na naši kontaktní < adresu.
< <Pokud máte příklad úspěšného nasazení PostgreSQL, přihlaště se na náš < advocacy site na http://advocacy.postgresql.org.
<Pro PostgreSQL existují dva ODBC ovladače - PsqlODBC a OpenLink ODBC.
< <PsqlODBC je ke stažení na http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
< <OpenLink můžete získat na http://www.openlinksw.com. Spolupracuje < s jejich klientským programovým vybavením a je dostupný pro všechny jimi < podporované platformy (Win, Mac, Unix, VMS).
< <Tento ovladač je určen pro ty, kteří vyžadují podporu komerční kvality, < nicméně freeware verze je dostupná a funkční. Dotazy zasílejte < na postgres95@openlink.co.uk.
< <Pěkný úvod do databázových technologií zabezpečujících chod < webových stránek najdete na http://www.webreview.com.
< <Pro tvorbu webu existuje excelentní rozhraní PHP, které naleznete na < http://www.php.net.
< <Pro složitější případy se často používá Perl a CGI.pm nebo mod_perl.
< <Pro PostgreSQL existuje několik grafických rozhraní: < PgAccess (http://www.php.net), PgAdmin (http://www.php.net), RHDB < Admin (http://sources.redhat.com/rhdb/) a Rekall < (http://www.thekompany.com/products/rekall/). Dále existuje < PHPPgAdmin (http://phppgadmin.sourceforge.net/) rozhraní < PostgreSQL založené na web technologii.
< <Úplnější seznam najdete na http://techdocs.postgresql.org/guides/GUITools.
< <Většina programovacích jazyků obsahuje rozhraní pro < PostgreSQL. Podívejte se do rozšiřujících modulů Vašeho programovacího < jazyka.
< <Distribuce PostgreSQL obsahuje tato rozhraní: <
Další rozhraní jsou dostupná na http://gborg.postgresql.org v sekci < Drivers/Interfaces.
<Použijte volbu --prefix při spuštění configure
< <Důvody mohou být různé, ale nejprve zkontrolujte, zda Váš systém < podporuje System V extensions. PostgreSQL vyžaduje v jádře podporu < sdílené paměti a semaforů.
< <Buďto nemáte správně nakonfigurovanou sdílenou paměť v jádře nebo < musite zvětšit její velikost. Potřebná velikost je závislá na < architektuře a na tom, kolik paměťových bufferů a backendů máte povoleno < pro postmastera. Pro většinu systémů s < předdefinovaným počtem backendů a paměťových bufferů je < minimum zhruba 1MB. V http://www.postgresql.org/docs/view.php?version=current&idoc=1&file=kernel-resources.html < naleznete podrobnější informace o sdílené paměti a semaforech.
< <Pokud dostane chybovou zprávu IpcSemaphoreCreate: semget failed (No < space left on device), pak vaše jádro nemá dost volných semaforů. PostgreSQL < vyžaduje jeden semafor pro každý backend v pozadí. Dočasným < řešením je start postmastera s limitem backendů. Použijte < přepínač -N s hodnotou menší než 32. Úplným řešením je zvýšení hodnot < SEMMNS a SEMMNI jadra.
< <Nefunkční semafory mohou způsobit pád během intenzivních databázových < operací.
< <Pokud se tato chyba vyskytuje ještě někde jinde, možná nemáte vůbec < nakonfigurovány semafory ve vašem jádře. V PostgreSQL < Administrator's Guide najdete podrobnější popis požadavků na sdílenou < pamět a semafory.
< <Při výchozím nastavení PostgreSQL odepře přístup z jiných stanic než < lokální s použitím UDP. Databáze se zpřístupní jiným stanicím < nastavením přepínače -i postmastera a povolením stanice a určením < režimu autentifikace v $PGDATA/pg_hba.conf. Tím se povolí TCP/IP < spojení. ZASTARALÉ
< <Určitě pomohou indexy. Příkaz EXPLAIN zobrazí způsob interpretace < Vašeho dotazu a použití indexů.
< <Při větší dávce INSERTů uvažujte o náhradě příkazem COPY. Ten je < mnohem rychlejší nežli samotný INSERT. Každý příkaz mimo blok < BEGIN WORK/COMMIT se provádí ve vlastní transakci. Zvažte, zda-li by < se nedalo několik příkazů spojit do jedné transakce. Tím se sníží < režie na transakce. Před provedením rozsáhlých změn zrušte indexy, < které po dokončení změn opět vytvořte.
< <Máte několik dalších možností, jak zlepšit výkon. Můžete zakázat fsyn() < při startu postmastera přepínači -o -F. Tyto přepínače zabrání < fsync(), tj. zápisu na disk po každé transakci.
< <Můžete zvýšit velikost paměťových bufferů použitých backendy < tj. parametr -B postmasteru. Pokud ale tato hodnota bude příliš < velká, tak možná nespustíte postmastera jelikož dosáhnete limitu < sdílené paměti. Každý buffer má 8K a implicitně je 64 bufferů.
< <Dále můžete použít přepínač -S k zvýšení limitu paměti pro backendy < na dočasné třídění. Hodnota je míněna v kilobytech a výchozí < nastavení je 512, tj. 512K.
< <Můžete použít příkaz CLUSTER, který uspořádá fyzicky data v < tabulkách podle indexu. Více na manuálových stránkách příkazu < CLUSTER.
< <Máte několik možností jak se dostat k užitečným stavovým informacím.
< <Zaprvé, při překladu použijte přepínač --enable-cassert, tím se zapne < monitorování a následné zastavení aplikace, když se proces v backendu < dostane do neočekávaného stavu.
< <Jak postmaster tak postgres má několik přepínačů umožňujících < ladění. Postmaster nastartujte tak, abyste si byli jisti, že je < standartní výstup a standartní chybový výstup přesměrován do souboru < logu, například:
<cd /usr/local/pgsql < ./bin/postmaster > server.log 2>&1 & <<
Tím se vytvoří log v adresáři PostgreSQL, Tento soubor obsahuje < užitečné informace o problémech a chybách vyskytlých se na < serveru. Postmaster má přepínač -d určující, jak podrobné mají být < reportované informace, tj. debug level. Pozor, při velké hodnotě debug < levelu rychle roste velikost souboru logu.
< <Pokud neběží postmaster, můžete spustit backend PostgreSQL z příkazové < řádky a napsat svůj SQL dotaz přímo v backendu (doporučeno pouze pro < ladění). Dotaz je v tomto případě ukončen novou řádkou, nikoliv < středníkem. Pokud máte aplikaci přeloženou s ladícími symboly, můžete < použít debbuger k monitorování procesu. Pokud není backend spuštěn < postmasterem, pak neběží ve svém obvyklém prostředí a tudíž některé problémy < dané interakcí mezi backendy nemohou být nasimulovány.
< <Pokud běží postmaster, spusťe psql v jednom okně a pak si zjistěte PID < procesu postgres použitého psql. V debuggeru sepřipojte k postgresql < PID. Pak nastavte breakpointy v debuggeru a zadejte dotaz v < psql. Pokud ladíte startup postgresu, pak nastavte PGOPTIONS="-W n" a < spusťe psql. Tento přepínač způsobí pauzu n sekund, takže budete mít < čas se připojit k procesu, a nastavit breakpointy a pokračovat v < startup posloupnosti.
< <Pro ladění a měření výkonu mohou být užitečné přepínače -s, -A a -t < programu postgres (backend).
< <Můžete provést překlad s profilací, tak abyste viděli kolik času < zabírají jednotlivé funkce. Soubory s profily backendů jsou uloženy v < adresáři pgsql/data/base/dbname. Profil klienta pak v jeho aktuálním < adresáři. Korektní profilace v prostředí Linux požaduje konfiguraci < systému s parametrem -DLINUX_PROFILE.
< <Zvyšte limit postmastera na maximální počet současně spuštěných backendů.
< <Výchozí hodnota je 32 backendů. Tuto hodnotu zvýšíte zastavením a < opětovným spuštěním postmastera s parametrem -N nebo úpravou postgresql.conf.
< <Při zvýšení hodnoty -N nad 32 musíte zvýšit hodnotu -B nad výchozí 64, < -B musí být minimálně dvakrát větší, nebo ještě lépe více. Pravděpodobně < zjistíte, že pro velký počet procesů backendu je nutné zvýšit některé < parametry jádra. Jsou to především maximální velikost sdílené paměti SHMMAX, < maximální počet semafórů SEMMNS a SEMMNI, maximální počet procesů NPROC, < maximální počet procesů uživatele MAXUPRC a maximální počet otevřených souborů < NFILE a NINODE. Důvod pro omezení maximálního počtu backendů je fakt, < že by mohlo dojít k vyčerpání zdrojů Vašeho systému.
< <Tento adresář obsahuje dočasné soubory vytvořené exekutorem < dotazů. Například, když je nutné třídění k zajištění ORDER BY a < třídění má větší nároky na prostor než povoluje parametr -S < backendu, pak je vytvořen dočasný soubor k uložení extra údajů.
< <Dočasné soubory jsou obvykle mazány automaticky, ale může se stát, že < během třídění server spadne. Zastavení a další start postmastera zajistí < odstranění souborů s těchto adresářů.
< <PostgreSQL se minimálně mění během malých verzí, takže např. při upgrade z < 7.2 na 7.2.1 není nutné dump a load databáze. Ale velké verze často mění < interní formát systémových tabulek a datových souborů. Tyto změny jsou < natolik rozsáhlé, že nelze zajistit zpětnou kompatibilitu pro datové < soubory. Dump uloží data v obecném formátu, takže mohou být načtena a < používána v novém interním formátu.
<Popis najdete v manuálové stránce DECLARE
< <Podívejte se do man. stránky příkazu FETCH, nebo použijte SELECT ... < LIMIT ...
< <Není nutné zpracovávat celý dotaz, když potřebujete pouze několik prvních < řádků. Pokud existuje index ORDER BY, PostgreSQL je schopen přerušit < zpracování dotazu po získání požadovaného počtu řádků.
< <K získání náhodného řádku použijte:
<SELECT col FROM tab < ORDER BY random() LIMIT 1; <<
Podívejte se do zdrojových kódů psql do souboru < pgsql/src/bin/psql/describe.c. Ten obsahuje SQL příkazy, které se < používají v psql metapříkazech. Dále můžete spustit psql s přepínačem < -E, který způsobí zobrazení každého dotazu, které zpracování < metapříkazu vyvolá.
< <Počínaje verzí 7.3 můžete použít příkaz ALTER TABLE DROP COLUMN. Ve < starších verzích můžete použít následující postup:
<BEGIN; < LOCK TABLE old_table; < SELECT ... -- mimo sloupec, který chceme odstranit < INTO TABLE new_table; < DROP TABLE old_table; < ALTER TABLE new_table RENAME TO old_table; < COMMIT; <<
Pro změnu typu sloupce je třeba provést:
<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; <<
Poté proveďte VACUUM FULL tab - uvolníte tím diskový prostor zabraný < nyní již neplatnými řádky.
< <PostgreSQL má tato omezení:
<Maximální velikost databáze: | neomezena (existují 32TB db) < |
Maximálné velikost tabulky: | 32 TB < |
Maximální velikost řádky: | 1.6 TB < |
Maximální velikost položky | 1 GB < |
Maximální počet řádků v tabulce: | neomezeno < |
Maximální počet sloupců v tabulce: | 250-1600 podle typů < |
Maximální počet indexů na tabulce: | neomezeno < |
Ve skutečnosti nic není neomezeno, limitem bývá vždy dostupná disková < paměť nebo velikost operační paměti. Pokud máte některou z těchto < hodnot neobvykle velkou, může dojít ke snížení výkonu.
< <Maximální velikost tabulky je 32 TB a nevyžaduje podporu velkých souborů < operačním systémem. Velké tabulky se ukládají do několika 1 GB souborů < takže limity souborového systému nejsou podstatné.
< <Maximální velikost tabulky a maximální počet sloupců můžeme < zečtyřnásobit nastavením velikosti bloku na 32K.
< <PostgreSQL vyžaduje až pětinásobek diskového prostoru k uložení dat z < textového souboru.
< <Například, uvažujme soubor se 100 tisíci řádky obsahující na každé < řádce celé číslo a textový popis. Text je v průměru dvacet bytů < dlouhý. Textový soubor bude 2.8 MB dlouhý. Velikost < databáze obsahující odpovídající data bude zhruba 6.4 MB.
<36 bytů: hlavička řádku (přibližně) < 24 bytů: jedna celočíselná položka a jedna textová < 4 byty: ukazatel na stránku k ntici < ------------------------------------------------------ < 64 bytů na řádek <<
Velikost datové stránky PostgreSQL je 8KB
<8192 bytů na stránce < ---------------------- = 128 řádek na stránku < 64 bytů za řádek < < 100000 řádek < -------------------- = 782 stránek (zaokrouhleno nahoru) < 128 řádek na stránce < < 782 * 8192 = 6, 406, 144 bytů (6.4 MB) <<
Indexy nemají tak velkou režii, ale mohou být také velké, < protože obsahují indexovaná data.
< <Hodnoty NULL jsou uloženy v bitmapách, takže spotřebují jen velmi málo < diskového prostoru.
< <psql má sadu metapříkazů k zobrazení těchto informací. Jejich seznam < získáte příkazem \?. Dále se můžete podívat na obsah systémových < tabulek začínajících pg_. Spuštění psql s parametrem -l provede < výpis názvů všech databází.
< <Soubor pgsql/src/tutorial/syscat.source obsahuje SELECTy přistupující < k systémovým tabulkámm.
< <Každý dotaz nemusí nutně použít existující indexy. Index se použije tehdy, < když je tabulka větší než určitá minimální velikost, a dotaz vybírá < pouze procentuálně malou část řádků tabulky. To proto, že náhodný < přístup k disku daný čtením indexu může být pomalejší než lineární < čtení tabulky nebo sekvenční čtení,
< <PostgreSQL rozhoduje o použití indexů na základě statistiky přístupů k < tabulce. Tyto statistiky se shromažďují příkazy VACUUM ANALYZE nebo < ANALYZE. Díky statistikám má optimizer informaci o počtu řádek v < tabulce a může lépe rozhodnout o použití indexů. Statistiky se uplatní < při určení optimálního pořadí a metody spojení tabulek. Statistiky by < se měli aktualizovat opakovaně, tak jak se mění obsah tabulek.
< <Indexy nejsou obyčejně použity pro setřídění nebo spojení < tabulek. Sekvenční zpracování následované explicitním tříděním je < obyčejně rychlejší než indexní čtení na velké tabulce.
< <Jinak je tomu v případě použití LIMIT a ORDER BY, při kterém se < většinou index použije, výsledkem je pouze malá část tabulky. Funkce < MAX() a MIN() nepoužívají indexy, ale je možné tutéž hodnotu získat
<SELECT col FROM tab < ORDER BY col [ DESC ] LIMIT 1; <<
Pokud si myslíte, že optimizer mylně zvolil sekvenční prohledávání < tabulky, použijte příkaz SET enable_seqscan TO 'off' a zkuste zda je < indexní prohledávání rychlejší.
< <Při vyhledávání na základě vzoru jako je např. operátor LIKE nebo ~ se < indexy použíjí pouze za určitých skutečností:
<Podívejte se do manuálové stránky příkazu EXPLAIN.
< <R-tree index se používá pro indexování prostorových dat. Hash index < nemůže obsloužit prohledávání oblastí. B-tree index může řídit < vyhledání oblastí v jedné dimenzi. R-tree index může podporovat hledání v < multidimenzionálních datech. Použijeme-li například R-tree index na < atributy typu point, pak systém může efektivně odpovědět na dotaz - < vyber všechny body uvnitř obdélníků.
< <Původní návrh R-tree je 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
< <Tyto materiály naleznete v Stonebraker's "Readings in Database Systems".
< <Vestavěné R-tree může sloužit k indexaci polygonů a < oblastí. Teoreticky můžeme R-tree použít i pro více dimenzí (jiné než 3D). < Ve skutečnosti ale takové rozšíření R-tree vyžaduje trochu práce a < ve součastnosti chybí dokumentace jak na to.
< <GEQO modul urychluje optimalizaci dotazů při spojování množství < tabulek metodou Genetických algoritmů (GA). To umožňuje získat < velkého množství variant spojení při neúplném prohledáváním.
< <Operátor ~ slouží k porování s regulárním výrazem, jeho modifikace *~ < představuje case insensitive vyhledávání. Jedná se o obdobu LIKE a < ILIKE.
< <Pro vyhledávání bez ohledu na velká malá písmena použijeme
<SELECT * FROM tab < WHERE lower(col) = 'abc'; <<
V tomto případě se nepoužije standardní index. Nicméně, použije se < funkcionální index, pokud jej vytvoříte
<CREATE INDEX tabindex ON tab (lower(col)); <<
Určíte pomocí IS NULL nebo IS NOT NULL
< <Typ Interní název Poznámka --- >
PosgreSQL má prvotřídní infrastrukturu od našeho začátku v roce 1996. > Vděčíme za to Marku Fournierovi, který založil a spravoval tuto > infrastrukturu několik let.
> >Kvalitní infrastruktura je velice důležitá pro každý open source > projekt. Předchází nedorozuměním, která velice zdržují pokrok v > projektu.
> >Tato infrastruktura není laciná. K jejímu zajištění je třeba stále > hradit určité měsíční a jednorázové částky. Pokud máte Vy nebo Vaše > společnost peníze, které nám můžete darovat, obraťe se na "http://store.pgsql.com/shopping/">http://store.pgsql.com/shopping/ a darujte je.
> >Ačkoliv webová stránka zmiňuje PostgreSQL, Inc. vklady jsou určeny pouze > k podpoře projektu PostgreSQL a nepodporují žádnou existující > společnost. Pokud to vyžadujete, můžete poslat kontrolu na naši > kontaktní adresu.
>Pokud máte příklad úspěšného nasazení PostgreSQL, přihlaště se na náš > advocacy site na http://advocacy.postgresql.org.
> >Pro PostgreSQL existují dva ODBC ovladače - PsqlODBC a OpenLink ODBC.
> >PsqlODBC je ke stažení na "http://gborg.postgresql.org/project/psqlodbc/projdisplay.php"> > http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
> >OpenLink můžete získat na http://www.openlinksw.com. > Spolupracuje s jejich klientským programovým vybavením a je dostupný pro všechny jimi > podporované platformy (Win, Mac, Unix, VMS).
> >Tento ovladač je určen pro ty, kteří vyžadují podporu komerční kvality, > nicméně freeware verze je dostupná a funkční. Dotazy zasílejte na "mailto:postgres95@openlink.co.uk">postgres95@openlink.co.uk.
> >Pěkný úvod do databázových technologií zabezpečujících chod webových > stránek najdete na http://www.webreview.com.
> >Pro tvorbu webu existuje excelentní rozhraní PHP, které naleznete na > http://www.php.net.
> >Pro složitější případy se často používá Perl a CGI.pm nebo mod_perl.
> >Pro PostgreSQL existuje několik grafických rozhraní: PgAccess > (http://www.php.net), PgAdmin III > (http://www.php.net), RHDB Admin > (http://sources.redhat.com/rhdb/) a Rekall ( > http://www.thekompany.com/products/rekall/). > Dále ještě PhpPgAdmin > (http://phppgadmin.sourceforge.net/) což je rozhraní PostgreSQL > založené na web technologii.
> >Úplnější seznam najdete na "http://techdocs.postgresql.org/guides/GUITools">http://techdocs.postgresql.org/guides/GUITools.
> >Většina programovacích jazyků obsahuje rozhraní pro PostgreSQL. > Podívejte se do rozšiřujících modulů Vašeho programovacího jazyka.
> >Distribuce PostgreSQL obsahuje tato rozhraní:
>Další rozhraní jsou dostupná na http://gborg.postgresql.org > v sekci Drivers/Interfaces.
>Použijte volbu --prefix při spuštění configure.
> >Důvody mohou být různé, ale nejprve zkontrolujte, zda Váš systém > podporuje System V extensions. PostgreSQL vyžaduje v jádře podporu > sdílené paměti a semaforů.
> >Buďto nemáte správně nakonfigurovanou sdílenou paměť v jádře nebo musite > zvětšit její velikost. Potřebná velikost je závislá na architektuře a na > tom, kolik paměťových bufferů a backendů máte povoleno pro postmastera. > Pro většinu systémů s předdefinovaným počtem backendů a paměťových > bufferů je minimum zhruba 1MB. V PostgreSQL Administrator's Guide > naleznete podrobnější informace o sdílené paměti a semaforech.
> >Pokud dostane chybovou zprávu IpcSemaphoreCreate: semget failed (No > space left on device), pak vaše jádro nemá dost volných semaforů. > PostgreSQL vyžaduje jeden semafor pro každý backend v pozadí. Dočasným > řešením je start postmaster s limitem backendů. Použijte přepínač -N s > hodnotou menší než 32. Úplným řešením je zvýšení hodnot SEMMNS > a SEMMNI jadra.
> >Nefunkční semafory mohou způsobit pád během intenzivních databázových > operací.
> >Pokud se tato chyba vyskytuje ještě někde jinde, možná nemáte vůbec > nakonfigurovány semafory ve vašem jádře. V PostgreSQL Administrator's > Guide najdete podrobnější popis požadavků na sdílenou pamět a semafory.
> >Při výchozím nastavení PostgreSQL odepře přístup z jiných stanic než > lokální s použitím UDP. Přístup z jiných strojů není možný dokud > jej nepovolíte nastavením tcpip_socket v postgresql.conf a určením > způsobu autentifikace v $PGDATA/pg_hba.conf.
> >Určitě pomohou indexy. Příkaz EXPLAIN ANALYZE Vám umožní sledovat > jak PostgreSQL interpretuje Váš dotaz a které indexy používá.
> >Při větší dávce INSERTů uvažujte o náhradě příkazem COPY. Ten je mnohem > rychlejší nežli samotný INSERT. Každý příkaz mimo blok BEGIN WORK/COMMIT > se provádí ve vlastní transakci. Zvažte, zda-li by se nedalo několik > příkazů spojit do jedné transakce. Tím se sníží režie na transakce. Před > provedením rozsáhlých změn zrušte indexy, které po dokončení změn opět > vytvořte.
> >Máte několik dalších možností, jak zlepšit výkon. Můžete zakázat fsyn() > při startu postmastera přepínači -o -F. Tyto přepínače zabrání fsync(), > tj. zápisu na disk po každé transakci.
> >Můžete zvýšit velikost paměťových bufferů použitých backendy tj. > parametr -B postmasteru. Pokud ale tato hodnota bude příliš velká, tak > možná nespustíte postmastera jelikož dosáhnete limitu sdílené paměti. > Každý buffer má 8K a implicitně je 64 bufferů.
> >Dále můžete použít přepínač -S k zvýšení limitu paměti pro backendy na > dočasné třídění. Hodnota je míněna v kilobytech a výchozí nastavení je > 512, tj. 512K.
> >Můžete použít příkaz CLUSTER, který uspořádá fyzicky data v tabulkách > podle indexu. Více na manuálových stránkách příkazu CLUSTER.
> >Máte několik možností jak se dostat k užitečným stavovým informacím.
> >Zaprvé, při překladu použijte přepínač --enable-cassert, tím se zapne > monitorování a následné zastavení aplikace, když se proces v backendu > dostane do neočekávaného stavu.
> >Jak postmaster tak postgres má několik přepínačů umožňujících ladění. > Postmaster nastartujte tak, abyste si byli jisti, že je standartní > výstup a standartní chybový výstup přesměrován do souboru logu, > například:
>> cd /usr/local/pgsql > ./bin/postmaster > server.log 2>&1 & >>
Tím se vytvoří log v adresáři PostgreSQL, Tento soubor obsahuje užitečné > informace o problémech a chybách vyskytlých se na serveru. Postmaster má > přepínač -d určující, jak podrobné mají být reportované informace, tj. > debug level. Pozor, při velké hodnotě debug levelu rychle roste velikost > souboru logu.
> >Pokud neběží postmaster, můžete spustit backend PostgreSQL z příkazové > řádky a napsat svůj SQL dotaz přímo v backendu (doporučeno pouze pro > ladění). Dotaz je v tomto případě ukončen novou řádkou, nikoliv > středníkem. Pokud máte aplikaci přeloženou s ladícími symboly, můžete > použít debbuger k monitorování procesu. Pokud není backend spuštěn > postmasterem, pak neběží ve svém obvyklém prostředí a tudíž některé > problémy dané interakcí mezi backendy nemohou být nasimulovány.
> >Pokud běží postmaster, spusťe psql v jednom okně a pak si zjistěte PID > procesu postgres použitého psql. V debuggeru sepřipojte k postgresql > PID. Pak nastavte breakpointy v debuggeru a zadejte dotaz v psql. Pokud > ladíte startup postgresu, pak nastavte PGOPTIONS="-W n" a spusťe psql. > Tento přepínač způsobí pauzu n sekund, takže budete mít čas se připojit > k procesu, a nastavit breakpointy a pokračovat v startup posloupnosti.
> >Pro ladění a měření výkonu mohou být užitečné přepínače -s, -A a -t > programu postgres (backend).
> >Můžete provést překlad s profilací, tak abyste viděli kolik času > zabírají jednotlivé funkce. Soubory s profily backendů jsou uloženy v > adresáři pgsql/data/base/dbname. Profil klienta pak v jeho aktuálním > adresáři. Korektní profilace v prostředí Linux požaduje konfiguraci > systému s parametrem -DLINUX_PROFILE.
> >Zvyšte limit postmastera na maximální počet současně spuštěných > backendů.
> >Výchozí hodnota je 32 backendů. Tuto hodnotu zvýšíte zastavením a > opětovným spuštěním postmastera s parametrem -N nebo úpravou > postgresql.conf.
> >Při zvýšení hodnoty -N nad 32 musíte zvýšit hodnotu -B nad výchozí 64, > -B musí být minimálně dvakrát větší, nebo ještě lépe více. Pravděpodobně > zjistíte, že pro velký počet procesů backendu je nutné zvýšit některé > parametry jádra. Jsou to především maximální velikost sdílené paměti > SHMMAX, maximální počet semafórů SEMMNS a SEMMNI, maximální počet > procesů NPROC, maximální počet procesů uživatele MAXUPRC a maximální > počet otevřených souborů NFILE a NINODE. Důvod pro omezení maximálního > počtu backendů je fakt, že by mohlo dojít k vyčerpání zdrojů Vašeho > systému.
> >Tento adresář obsahuje dočasné soubory vytvořené exekutorem dotazů. > Například, když je nutné třídění k zajištění ORDER BY a třídění má větší > nároky na prostor než povoluje parametr -S backendu, pak je vytvořen > dočasný soubor k uložení extra údajů.
> >Dočasné soubory jsou obvykle mazány automaticky, ale může se stát, že > během třídění server spadne. Zastavení a další start postmastera zajistí > odstranění souborů s těchto adresářů.
> >PostgreSQL se minimálně mění během malých verzí, takže např. při upgrade > z 7.2 na 7.2.1 není nutné dump a load databáze. Ale výynamné verze často > mění interní formát systémových tabulek a datových souborů. Tyto změny > jsou natolik rozsáhlé, že nelze zajistit zpětnou kompatibilitu pro > datové soubory. Dump uloží data v obecném formátu, takže mohou být > načtena a používána v novém interním formátu.
> >Popis najdete v manuálové stránce DECLARE
> >Podívejte se do man. stránky příkazu FETCH, nebo použijte SELECT ... > LIMIT ...
> >I když potřebujete získat pouze prvních několik řádků, je třeba > zpracovat všechna data, např. pokud dotaz má ORDER BY. Pokud však > existuje index, který odpovídá ORDER BY, PostgreSQL může získat > pouze prvních n řádků a ukončit zpracování dotazu.
> >K získání náhodného řádku použijte:
>> SELECT col > FROM tab > ORDER BY random() > LIMIT 1; >>
Příkaz \dt v psql zobrazí seznam tabulek. Úplný seznam příkazů psql > dostanete příkazem \?. Také se můžete podívat do zdrojových kódů psql > do souboru pgsql/src/bin/psql/describe.c. Ten obsahuje SQL příkazy, > které se používají v psql metapříkazech. Dále můžete spustit psql > s přepínačem -E, který způsobí zobrazení každého dotazu, které > zpracování metapříkazu vyvolá. PostgreSQL nabízí SQLi INFORMATION > SCHEMA s tabulkami obsahující informace o databázi.
> >Počínaje verzí 7.3 můžete použít příkaz ALTER TABLE DROP COLUMN. Ve > starších verzích můžete použít následující postup:
>> BEGIN; > LOCK TABLE old_table; > SELECT ... -- mimo sloupec, který chceme odstranit > INTO TABLE new_table; > DROP TABLE old_table; > ALTER TABLE new_table RENAME TO old_table; > COMMIT; >>
Pro změnu typu sloupce je třeba provést:
>> 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; >> Poté proveďte VACUUM FULL tab - uvolníte tím diskový prostor zabraný > nyní již neplatnými řádky. > >
PostgreSQL má tato omezení:
>> Maximální velikost databáze: neomezena (existují 32TB db) > Maximálné velikost tabulky: 32 TB > Maximální velikost řádky: 1.6 TB > Maximální velikost položky 1 GB > Maximální počet řádků v tabulce: neomezeno > Maximální počet sloupců v tabulce: 250-1600 podle typů > Maximální počet indexů na tabulce: neomezeno >>
Ve skutečnosti nic není neomezeno, limitem bývá vždy dostupná disková > paměť nebo velikost operační paměti. Pokud máte některou z těchto hodnot > neobvykle velkou, může dojít ke snížení výkonu.
> >Maximální velikost tabulky je 32 TB a nevyžaduje podporu velkých souborů > operačním systémem. Velké tabulky se ukládají do několika 1 GB souborů > takže limity souborového systému nejsou podstatné.
> >Maximální velikost tabulky a maximální počet sloupců můžeme > zečtyřnásobit nastavením velikosti bloku na 32K.
> >PostgreSQL vyžaduje až pětinásobek diskového prostoru k uložení dat z > textového souboru.
> >Například, uvažujme soubor se 100 tisíci řádky obsahující na každé řádce > celé číslo a textový popis. Text je v průměru dvacet bytů dlouhý. > Textový soubor bude 2.8 MB dlouhý. Velikost databáze obsahující > odpovídající data bude zhruba 6.4 MB.
>> 36 bytů: hlavička řádku (přibližně) > 24 bytů: jedna celočíselná položka a jedna textová > + 4 byty: ukazatel na stránku k ntici > ------------------------------------------------------ > 64 bytů na řádek > > Velikost datové stránky PostgreSQL je 8KB > > 8192 bytů na stránce > ---------------------- = 128 řádek na stránku > 64 bytů za řádek > > 100000 řádek > -------------------- = 782 stránek (zaokrouhleno nahoru) > 128 řádek na stránce > > 782 * 8192 = 6, 406, 144 bytů (6.4 MB) >>
Indexy nemají tak velkou režii, ale mohou být také velké, protože > obsahují indexovaná data.
> >Hodnoty NULL jsou uloženy v bitmapách, takže spotřebují jen velmi málo > diskového prostoru.
> >psql má sadu metapříkazů k zobrazení těchto informací. Jejich seznam > získáte příkazem \?. Dále se můžete podívat na obsah systémových tabulek > začínajících pg_. Spuštění psql s parametrem -l provede výpis názvů > všech databází.
> >Soubor pgsql/src/tutorial/syscat.source obsahuje SELECTy přistupující k > systémovým tabulkámm.
> >Každý dotaz nemusí nutně použít existující indexy. Index se použije > tehdy, když je tabulka větší než určitá minimální velikost, a dotaz > vybírá pouze procentuálně malou část řádků tabulky. To proto, že náhodný > přístup k disku daný čtením indexu může být pomalejší než lineární čtení > tabulky nebo sekvenční čtení.
> >PostgreSQL rozhoduje o použití indexů na základě statistiky přístupů k > tabulce. Tyto statistiky se shromažďují příkazy VACUUM ANALYZE nebo > ANALYZE. Díky statistikám má optimizer informaci o počtu řádek v tabulce > a může lépe rozhodnout o použití indexů. Statistiky se uplatní při > určení optimálního pořadí a metody spojení tabulek. Statistiky by se > měli aktualizovat opakovaně, tak jak se mění obsah tabulek.
> >Indexy nejsou obyčejně použity pro setřídění nebo spojení tabulek. > Sekvenční zpracování následované explicitním tříděním je obyčejně > rychlejší než indexní čtení na velké tabulce.
> >Jinak je tomu v případě použití LIMIT a ORDER BY, při kterém se většinou > index použije, výsledkem je pouze malá část tabulky. Funkce MAX() a > MIN() nepoužívají indexy, ale je možné tutéž hodnotu získat: >
> SELECT col > FROM tab > ORDER BY col [ DESC ] > LIMIT 1; >>
Pokud si myslíte, že optimizer mylně zvolil sekvenční prohledávání
> tabulky, použijte příkaz SET enable_seqscan TO 'off'
a zkuste zda je
> indexní prohledávání rychlejší.
Při vyhledávání na základě vzoru jako je např. operátor LIKE nebo ~ se > indexy použíjí pouze za určitých skutečností:
>R-tree index se používá pro indexování prostorových dat. Hash index > nemůže obsloužit prohledávání oblastí. B-tree index může řídit vyhledání > oblastí v jedné dimenzi. R-tree index může podporovat hledání v > multidimenzionálních datech. Použijeme-li například R-tree index na > atributy typu point, pak systém může efektivně odpovědět na dotaz - > vyber všechny body uvnitř obdélníků.
> >Původní návrh R-tree je 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
> >Tyto materiály naleznete v Stonebraker's "Readings in Database Systems".
> >Vestavěné R-tree může sloužit k indexaci polygonů a oblastí. Teoreticky > můžeme R-tree použít i pro více dimenzí (jiné než 3D). Ve skutečnosti > ale takové rozšíření R-tree vyžaduje trochu práce a ve součastnosti > chybí dokumentace jak na to.
> >GEQO modul urychluje optimalizaci dotazů při spojování množství tabulek > metodou Genetických algoritmů (GA). To umožňuje získat velkého množství > variant spojení při neúplném prohledáváním.
> >Operátor ~ slouží k porování s regulárním výrazem, jeho modifikace *~ > představuje case insensitive vyhledávání. Jedná se o obdobu LIKE a > ILIKE.
> >Pro vyhledávání bez ohledu na velká malá písmena použijeme:
>> SELECT * > FROM tab > WHERE lower(col) = 'abc'; >> V tomto případě se nepoužije standardní index. Nicméně, použije se > funkcionální index, pokud jej vytvoříte: >
> CREATE INDEX tabindex ON tab (lower(col)); >>
Určíte pomocí IS NULL nebo IS NOT NULL
> >> Typ Interní název Poznámka 798,1088c859,1167 < VARCHAR(n) varchar omezeno maximální délkou, bez doplnění mezerami < CHAR(n) bpchar řetězec je doplněn mezerami do dané délky < TEXT text bez horního limitu na délku < BYTEA bytea pole bytů (bezpečně lze uložit i znak NULL) < "char" char jeden znak <<
S interními názvy se setkáte v systémovém katalogu a v některých < chybových hlášeních.
< <První čtyři uvedené typy jsou tzv. varlena typy (tj. první čtyři byty < na disku nesou údaj o délce, následují samotná data). Proto skutečný < použitý prostor je vždy o něco málo větší než deklarovaná délka. Naopak, < tyto datové typy jsou komprimovánty TOASTem, takže prostor na disku < může být nižší než je očekáváno.
< <VARCHAR(n) je vhodný pro ukládání textů promměné délky s pevně < stanovenou maximální délkou. TEXT je pro řetězce bez omezení délky s < maximem jeden gigabajt.
< <CHAR(n) slouží k ukládání řetězců stejné délky. CHAR(n) doplní prázdné < znaky do specifikované délky, zatímco VARCHAR(n) uloží pouze předané < znaky. BYTEA je určeno pro ukládání binárních dat, včetně NULL < byte. Všechny zde popsané typy mají podobné výkonnostní < charakteristiky.
< <PostgreSQL podporuje typ SERIAL. Při jeho použití se automaticky < vytvoří SEQUENCE a index na sloupci (Pro vyšší verze to neplatí < OVĚŘIT). Například:
<CREATE TABLE person ( < id SERIAL, < name TEXT < ); << je automaticky převedeno do <
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); <<
Viz dokumentace create_sequence v manuálových stránkách. Dále můžete použít < unikátní hodnotu OID každého řádku. Potom ale musíte spouštět pg_dump < s přepínačem -o, tak aby zůstaly zachovány hodnoty OID (u příkazu < copy COPY WITH OIDS).
< <Jednou z možností je získat budoucí hodnotu SERIAL funkcí nextval před < samotným vložením a pak ji vložit explicitně. Například v jakémsi < pseudojazyku
<newid = execute("SELECT nextval('person_id_seq')"); < execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')"); <<
Můžete pak ještě použít hodnotu newid v dalších dotazech, např. jako < hodnotu cizího klíče. Název automaticky vytvořené sekvence je < tabulka_sloupec_seq.
< <Alternativně můžete získat hodnotu posledně generovou sekvencí funkcí < currval() po vložení
<execute("INSERT INTO person (name) VALUES ('Blaise Pascal')"); < new_id = execute("SELECT currval('person_id_seq')"); <<
Konečně můžete použít OID hodnotu vrácenou příkazem INSERT, ale to je < pravděpodobně nejméně přenositelné řešení. V Perlu při použití DBI < modulu Edmunda Mergleho DBD:Pg oid hodnotu získáme < $sth->{pg_oid_status} po každém $sth->execute().
< <Nikoliv, currval() vrací hodnotu naposledy generovanou ve vašem < backendu, a ta tudíž není společná všem uživatelům.
< <K zajištění efektivnosti souběhu, jsou hodnoty posloupnosti, když se o ně < požádá, a sekvence není zamčena do ukončení transakce. To způsobuje < díry v číslování ze zrušených transakcí.
< <Každý řádek vytvořený v PostgreSQL získá jedinečné OID. Všechna OID < generovaná během inicializace databáze jsou menší než 16384 < (include/access/transam.h). Všechna OID generovaná na požadavek < uživatele jsou rovna nebo vyšší této hodnotě. Normálně, všechna OID < jsou jedinečná nejen uvnitř tabulky nebo databáze, ale v rámci celé < instalace PostgreSQL
< <PostgreSQL používá OID ve svém interním systému tabulek k vytvoření < relací. Tato OID mohou být použita k identifikaci konkrétního < uživatele a použita v spojení. Pro OID hodnoty je doporučen typ < OID. Nad tímto sloupcem můžete vytvořit index pro urychlení přístupu.
< <OID jsou dána všem řádkům z centrální oblasti a jsou použita v každé < databázi. Pokud potřebujete změnit OID, nebo chcete zkopírovat tabulku < s původními OID, lze použít
<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'; <<
OID jsou uložena jako 4bajtový integer a přetečou po čtyřech < miliardách. Nebylo hlášeno, že by se tak někdy stalo, přesto ale plánujeme < odstranit tento limit dřív než se tak stane.
< <TID se používají i identifikaci fyzických řádků s hodnotou bloku a < offsetu. TIDs se mění modifikací řádků (používá se jako ukazatel < indexu fyzického řádku).
< <V některých zdrojových kódech nebo starší dokumentaci se můžete setkat < s následujícími výrazy, které mají širší význam. Zde je příklad < nekterých:
<seznam těchto výrazů můžete nalézt na < http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html.
< <Pravděpodobně došlo k vyčerpání virtuální paměťi na Vašem systému, nebo < jádro má nízký limit pro určité zdroje. Vyzkoušejte před startem < posmatera
<ulimit -d 262144 < limit datasize 256m <<
Záleží na Vašem shellu, zda budou tyto příkazy úspěšné, měly by zvýšit < limit datového segmentu pro Vaše procesy a umožnit tak dokončení < dotazu. Tyto příkazy se aplikují na aktuální proces a všechny synovské < procesy vytvořené po provedení příkazu. Pokud máte problémy s SQL < klientem protože backend vrací příliš mnoho dat, zkuste zvýšit limity < před startem klienta.
< <V psql spusťte
<SELECT version(); <<
Všechny operace s velkými objekty - lo_open, lo_close, ... musíte < spouštět v transakci, tj. mezi příkazy BEGIN WORK a COMMIT.
< <PostgreSQL uvolňuje handle velkých objektů při skončení transakce. Pokud < budete pracovat s velkými objekty mimo transakci, pravděpodobně dostanete < toto chybové hlášení, protože handle již budou neplatné.
< <Pokud používáte interface podobné ODBC musíte nastavit set auto_commit off
< <Použijte CURRENT_TIMESTAMP
<CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP ); <<
Aktuálně spojujeme tabulky se sekvenčním skenováním výsledku pro každý < řádek vnějšího dotazu. Pokud vnořený dotaz má pouze několik řádků a < vnější dotaz vrací hodně řádek, IN je rychlé. V jiných případech < nahraďte IN EXISTS:
<SELECT * FROM tab < WHERE col IN (SELECT subcol FROM subtab); << takto <
SELECT * FROM tab < WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col); <<
Pro urychlení vytvořete index pro subcol. Tento výkonnostní problém < byl odstraněn ve verzi 7.4.
< <PostgreSQL podporuje vnější spojení tabulek standardními SQL < příkazy. Zde jsou dva příklady:
<SELECT * FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col); << nebo <
SELECT * FROM t1 LEFT OUTER JOIN USING (col); <<
Tyto identické dotazy napojí t1.col na t2.col a ještě přidá < nepřipojené řádky z t1 (které nemají obdoby v t2). Pravé spojení < (RIGHT JOIN) přidá nepřipojené řádky z t2. FULL JOIN vrátí všechny < řádky, včetně nepřipojených z tbulek t1 a t2. Klíčové slovo OUTER je < nepovinné a váže se na LEFT, RIGHT a FULL join. Běžné spojení se < nazývá INNER JOIN.
< <V dřívějších verzích se vnější spojení tabulek mohlo simulovat pomocí < UNION a NOT IN. Například pro spojení tabulek tab1 a tab2, je < následující dotaz ekvivalentní k vnějšímu spojení dvou tabulek:
<SELECT tab1.col2, tab2.col2 FROM tab1, tab2 < WHERE tab1.col1 = tab2.col1 < UNION ALL < SELECT tab1.col2, NULL FROM tab1 < WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2) < ORDER BY col1; <<
PostgreSQL nenabízí žádný způsob, jak se dotázat do jiné databáze než < do aktuální. Doplněk contrib/dblink umožňuje dotaz do cizí databáze < prostřednictvím funkce. Na straně klienta není problém si otevřít více < simultálních přístupů do různých databází a spojovat výsledek na < straně klienta.
< <V PostgreSQL 7.3 můžete jednoduše vracet více řádků nebo sloupců z < funkce, viz: < http://techdocs.postgresql.org/guides/SetReturningFunctions.
< <Existuje několik dostupných řešení master/slave replikací. Ty povolují < modifikace master databáze a slave databázím umožňují pouze čtení. Na < konci http://gborg.PostgreSQL.org/genpage?replication_research < najdete jejich seznam. Na řešení multi-master replikaci se pracuje na < http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
< <contrib/pgcrypto obsahuje šifrovací funkce použitelné v SQL < dotazech.
< <K šifrování přenosu dat z klienta na server, musí být < server přeložen s podporou ssl a přepínač sslv postgresql.conf musí < být nastaven na hodnotu true. Klient musí mít vytvořen záznam < hostssl v pg_hba.conf a také mít povolen režim ssl. Lze použít i jiné < prostředky, nejen nativní podporu ssl v PostgreSQL, např. stunel a ssh.
< <Hesla uživatelů databáze jsou zašifrována počínaje verzí 7.3. Ve < starších verzích toto chování muselo být vynuceno volbou < PASSWORD_ENCRYPTION v postgresql.conf
< <Server může běžet na šifrovaném souborovém systému.
<Problém může být způsoben mnoha okolnostmi. Vyzkoušejte si svoji < funkci nejdříve v nějaké jednoduché aplikaci.
< <Pošlete své rozšíření do konference pgsql-hackers, a ono pak možná < skončí v podadresáři contrib.
< <Funkce vracející tabulky jsou podporované PostgreSQL 7.3 a vyšší pro < jazyky C, PL/PgSQL a SQL. Více naleznete v The Programmer's < Guide. Příklady těchto funkcí pro C naleznete v contrib/tablefunc.
< <Makefile nemá informace o závislostech mezi hlavičkovými soubory. Musíte < provést make clean a pak make. Pokud používáte gcc, můžete použít < přepínač --enable-depend příkazu configure k automatickému řešení < závislostí překladačem.
< \ Chybí znak konce řádku na konci souboru --- > VARCHAR(n) varchar omezeno maximální délkou, bez doplnění mezerami > CHAR(n) bpchar řetězec je doplněn mezerami do dané délky > TEXT text bez horního limitu na délku > BYTEA bytea pole bytů (bezpečně lze uložit i znak NULL) > "char" char jeden znak > >S interními názvy se setkáte v systémovém katalogu a v některých > chybových hlášeních.
> >První čtyři uvedené typy jsou tzv. varlena typy (tj. první čtyři byty na > disku nesou údaj o délce, následují samotná data). Proto skutečný > použitý prostor je vždy o něco málo větší než deklarovaná délka. Naopak, > tyto datové typy jsou komprimovánty TOASTem, takže prostor na disku může > být nižší než je očekáváno.
> >VARCHAR(n) je vhodný pro ukládání textů promměné délky s pevně > stanovenou maximální délkou. TEXT je pro řetězce bez omezení délky s > maximem jeden gigabajt.
> >CHAR(n) slouží k ukládání řetězců stejné délky. CHAR(n) doplní prázdné > znaky do specifikované délky, zatímco VARCHAR(n) uloží pouze předané > znaky. BYTEA je určeno pro ukládání binárních dat, včetně NULL byte. > Všechny zde popsané typy mají podobné výkonnostní charakteristiky.
> >PostgreSQL podporuje typ SERIAL. Při jeho použití se automaticky vytvoří > SEQUENCE. Například:
>> CREATE TABLE person ( > id SERIAL, > name TEXT > ); >> je automaticky převedeno do >
> 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); >> Viz dokumentace create_sequence v manuálových stránkách. Dále můžete > použít unikátní hodnotu OID každého řádku. Potom ale musíte spouštět > pg_dump s přepínačem -o, tak aby zůstaly zachovány hodnoty OID (u > příkazu copy COPY WITH OIDS). > >
Jednou z možností je získat budoucí hodnotu SERIAL funkcí nextval() před > samotným vložením a pak ji vložit explicitně. Například v jakémsi > pseudojazyku:
>> newid = execute("SELECT nextval('person_id_seq')"); > execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')"); >>
Můžete pak ještě použít hodnotu newid v dalších dotazech, např. jako > hodnotu cizího klíče. Název automaticky vytvořené sekvence je > tabulka_sloupec_seq.
> >Alternativně můžete získat hodnotu posledně generovou sekvencí funkcí > currval() po vložení:
>> execute("INSERT INTO person (name) VALUES ('Blaise Pascal')"); > new_id = execute("SELECT currval('person_id_seq')"); >>
Konečně můžete použít OID hodnotu vrácenou příkazem INSERT, ale to je > pravděpodobně nejméně přenositelné řešení. V Perlu při použití DBI > modulu Edmunda Mergleho DBD:Pg oid hodnotu získáme $sth->{pg_oid_status} > po každém $sth->execute(). > >
Nikoliv, currval() vrací hodnotu naposledy generovanou ve vašem > backendu, a ta tudíž není společná všem uživatelům.
> >K zajištění efektivnosti souběhu, jsou hodnoty posloupnosti, když se o > ně požádá, a sekvence není zamčena do ukončení transakce. To způsobuje > díry v číslování ze zrušených transakcí.
> >Každý řádek vytvořený v PostgreSQL získá jedinečné OID. Všechna OID > generovaná během inicializace databáze jsou menší než 16384 > (include/access/transam.h). Všechna OID generovaná na požadavek > uživatele jsou rovna nebo vyšší této hodnotě. Normálně, všechna OID jsou > jedinečná nejen uvnitř tabulky nebo databáze, ale v rámci celé instalace > PostgreSQL
> >PostgreSQL používá OID ve svém interním systému tabulek k vytvoření > relací. Tato OID mohou být použita k identifikaci konkrétního uživatele > a použita v spojení. Pro OID hodnoty je doporučen typ OID. Nad tímto > sloupcem můžete vytvořit index pro urychlení přístupu.
> >OID jsou dána všem řádkům z centrální oblasti a jsou použita v každé > databázi. Pokud potřebujete změnit OID, nebo chcete zkopírovat tabulku s > původními OID, lze použít:
>> 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'; >>
OID jsou uložena jako 4bajtový integer a přetečou po čtyřech miliardách. > Nebylo hlášeno, že by se tak někdy stalo, přesto ale plánujeme odstranit > tento limit dřív než se tak stane.
> >TID se používají i identifikaci fyzických řádků s hodnotou bloku a > offsetu. TIDs se mění modifikací řádků (používá se jako ukazatel indexu > fyzického řádku).
> >V některých zdrojových kódech nebo starší dokumentaci se můžete setkat s > následujícími výrazy, které mají širší význam. Zde je příklad nekterých:
>seznam těchto výrazů můžete nalézt na > http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html.
> >Pravděpodobně došlo k vyčerpání virtuální paměťi na Vašem systému, nebo > jádro má nízký limit pro určité zdroje. Vyzkoušejte před startem > posmatera
>> ulimit -d 262144 > limit datasize 256m >>
Záleží na Vašem shellu, zda budou tyto příkazy úspěšné, měly by zvýšit > limit datového segmentu pro Vaše procesy a umožnit tak dokončení dotazu. > Tyto příkazy se aplikují na aktuální proces a všechny synovské procesy > vytvořené po provedení příkazu. Pokud máte problémy s SQL klientem > protože backend vrací příliš mnoho dat, zkuste zvýšit limity před > startem klienta.
> >V psql spusťte SELECT version();
Všechny operace s velkými objekty - lo_open
, lo_close
, ... musíte
> spouštět v transakci, tj. mezi příkazy BEGIN WORK
a COMMIT
.
PostgreSQL uvolňuje handle velkých objektů při skončení transakce. Pokud > budete pracovat s velkými objekty mimo transakci, pravděpodobně > dostanete toto chybové hlášení, protože handle již budou neplatné.
> > Pokud používáte interface podobné ODBC musíte nastavitset
> auto_commit off
.
>
> Použijte CURRENT_TIMESTAMP:
>
>
> CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
>
>
> Dřívější verze (před 7.4) spojovali vnořené dotazy k vnějším sekvenčním > čtením výsledku poddotazu pro každý řádek vnějšího dotazu. Pokud poddotaz > vrátil několik málo řádků IN bylo rychlé. Pro ostatní případy je vhodné > nahradit IN EXISTS: >
> SELECT * > FROM tab > WHERE col IN (SELECT subcol FROM subtab); >> na: >
> SELECT * > FROM tab > WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col); >>
Pro urychlení vytvořete index pro subcol.
> >Ve verzi 7.4 a pozdějších, IN používá stejně sofistikovanou techniku > spojování tabulek jako ostatní dotazy a je preferovaný před EXISTS.
> >PostgreSQL podporuje vnější spojení tabulek standardními SQL příkazy. > Zde jsou dva příklady:
>> SELECT * > FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col); >> nebo >
> SELECT * > FROM t1 LEFT OUTER JOIN USING (col); >>
Tyto identické dotazy napojí t1.col na t2.col a ještě přidá nepřipojené > řádky z t1 (které nemají obdoby v t2). Pravé spojení (RIGHT JOIN) přidá > nepřipojené řádky z t2. FULL JOIN vrátí všechny řádky, včetně > nepřipojených z tbulek t1 a t2. Klíčové slovo OUTER je nepovinné a váže > se na LEFT, RIGHT a FULL join. Běžné > spojení se nazývá INNER JOIN.
> >V dřívějších verzích se vnější spojení tabulek mohlo simulovat pomocí > UNION a NOT IN. Například pro spojení tabulek tab1 a tab2, je > následující dotaz ekvivalentní k vnějšímu spojení dvou tabulek:
>> SELECT tab1.col2, tab2.col2 > FROM tab1, tab2 > WHERE tab1.col1 = tab2.col1 > UNION ALL > SELECT tab1.col2, NULL > FROM tab1 > WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2) > ORDER BY col1; >> >
PostgreSQL nepodporuje dotazy do jiné než aktuální databáze.
> >contrib/dblink nabízí funkce umožňující provedení dotazu v jiné > databázi. Klient si může otevřít simultální připojení do různých > db bez omezení.
> >V PostgreSQL 7.3 můžete jednoduše vracet více řádků nebo sloupců z > funkce, viz: > http://techdocs.postgresql.org/guides/SetReturningFunctions. > >
Přeložený kód PL/pgSQL funkce je uložen ve vyrovnávací paměti, tj. > funkce je překládána pouze při změně kódu, nikoliv před každým voláním > funkce. Nechtěným vedlejším efektem je, že volání funkce selže, když se > funkce odkazuje na dočasnou tabulku, pokud tato tabulka byla od překladu > funkce zrušena (ačkoliv již byla znovu vytvořena a existuje). Jediným > řešením problému je přístup k dočasné tabulce pomocí EXECUTE, tj. > dynamické provádění dotazu. Tento příkaz zajistí opakovaný překlad > dotazu při každém volání funkce.
> >Existuje několik dostupných řešení master/slave replikací, tj umožňují > modifikace master databáze a slave databázím umožňují pouze čtení. Na > konci http://gborg.PostgreSQL.org/genpage?replication_research najdete > jejich seznam. Na řešení multi-master replikaci se pracuje na > http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
> >Problém může být způsoben mnoha okolnostmi. Vyzkoušejte si svoji funkci > nejdříve v nějaké jednoduché aplikaci.
> >Pošlete své rozšíření do konference pgsql-hackers, a ono pak možná > skončí v podadresáři contrib.
> >Funkce vracející tabulky jsou podporované PostgreSQL 7.3 a vyšší pro > jazyky C, PL/PgSQL a SQL. Více naleznete v The Programmer's Guide. > Příklady těchto funkcí pro C naleznete v contrib/tablefunc.
> >Makefile nemá informace o závislostech mezi hlavičkovými soubory. Musíte > provést make clea