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 endna 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.
Na naší mailové konferenci můžete kontaktovat velkou skupinu vývojářů a uživatelů.problémů. Nemůžeme garantovat opravu, nicméně komerční databáze také ne vždy nabídnou opravu. Podle ohlasů je naše podpora hodnocena lépe než u jiných DBMS a to díky přímému kontaktu s vývojáři, velkou komunitou uživatelů, kvalitními manuály a přístupným zdrojovým kódem. Pro uživatele, kteří vyžadují podporu ke konkrétním případům, existuje placená podpora (FAQ sekce 1.6).
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 -------------------------------------------------------------------------- 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.