PostgreSQL patří k robustním a na schopnosti bohatým databázím. Ve stejném duchu byl veden i vývoj verze 7.1. Kdo očekával snahu dohánět pekelnou rychlost MySQL bude zklamán, naopak kdo očekával šlapání na paty Larry Ellisona bude potěšen :-)
Dost dlouho bylo PostgreSQL vyčítáno, že má omezení velikosti řádky (tuple) tabulky, která mohla být maximálně 32Kb, což vedlo k problémům při ukládání např. dlouhých textů. Již ve verzi 7.0 bylo uděláno několik změn, které se staly podkladem pro finální řešení, které najdete v 7.1. Někdo by se možná zeptal, v čem je problém při ukládání např. 40Kb dat, když lze uložit 32Kb. Je to dáno nutností bufferovat přístup k datům. Pokud budete data načítat do nějakého bufferu v kterém je budete zpracovávat tak dříve nebo později narazíte na nějaký limit (minimálně na omezení velikosti paměti). Proto se v PostgreSQL pracuje s defaultně s 8–32Kb buffery. Řešení, jak dlouhá data rozdělovat na menší bloky a ty samostatně ukládat, se v PostgreSQL jmenuje TOAST.
TOAST velmi zjednodušeně pracuje tak, že dlouhá data rozdělí na menší bloky (chunky) a ty ukládá do speciálních interních SQL tabulek. Pokud pak uživatel požádá např. příkazem SELECT o data tak jsou v této tabulce nalezeny potřebné chunky ze kterých se poskládají data která dostane uživatel. To znamená, že čím větší data tím pochopitelně pomalejší, ale zároveň toto řešení nemá žádný limit co do velikosti uložených dat. TOAST implementoval Jan Weick.
Další velkou změnou je WAL – write ahead log od Vadima Mikheeva. Vadim je guru na řešení transakcí (MVCC – multi-version concurrency control) a optimalizací zapisování dat (storage management). V podobném duchu se nese i WAL. Dřívější verze databáze všechny modifikace dat zapisovala ihned do příslušných souborů. To se pochopitelně podepisovalo na výkonosti databáze, částečným řešením bylo riskantní vypnutí fsync() pomocí parametru „-F“. WAL na místo toho všechna modifikovaná data zapisuje do jednoho logu a až po uplynutí nějaké doby tyto data přesunuje do souborů dané tabulky (ve skutečnosti je to trošku složitější, jsou do toho zamontovány i transakce, v logu se udržují tzv. checkpointy apod. – prostě nic co by musel normální uživatel chápat :-). V konečném důsledku to znamená větší rychlost při zachování bezpečnosti dat – na rozdíl od potlačení fsync. Ale i tak potlačení fsync() je stále nejrychlejší varianta jak provozovat PostgreSQL – pochopitelně tato volba očekává, že vedle počítače máte UPS. Vývoj v oblasti storage managementu je slibován i pro další verze.
Další velká změna nebyla až tak vývojářsky individuální záležitost jako dvě předchozí, ale o to zajímavější je. Ano, PostgreSQL konečně kompletně podporuje OUTER JOIN, a to dle syntaxe SQL92. Jedná se tedy o možnost spojení dvou a více tabulek pomocí JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN, CROSS JOIN v rámci příkazu SELECT. To je jistě radostná informace pro každého (včetně mě), kdo byl dříve tento nedostatek nucen řešit pomocí dotazů obsahujících UNION. Více řekne následující ukázka:
test=# SELECT t1.id, t1.data, t2.id, t2.data
FROM t1 FULL JOIN t2 USING (id);
id | data | id | data
----+------+----+------
1 | aaa | 1 | 2aaa
2 | bbb | 2 | 2bbb
| | 3 | 2ccc
4 | ddd | 4 | 2ddd
5 | eee | 5 | 2eee
6 | fff | |
(6 rows)
Další velkou, i když pro uživatele neviditelnou změnou je přepsání function manageru (fmgr). Jak známo PostgreSQL umožňuje uživatelům definovat si vlastní funkce v téměř libovolném jazyce. Nová podoba funkcí je teď modernější a předávání parametrů se podobá např. tomu, jak to interně dělá Python nebo PHP (také rádi studujete cizí programy? :-). Tom Lane, který se v této věci angažoval, odvedl opravdu velkou práci, protože bylo nutno přepsat téměř všechny built-in funkce.
I pod další, na povrchu neviditelnou změnou je podepsán Tom Lane (Tom je opravdový guru jakých na světě noc není – na toto jméno si můžete vzpomenou vždy, když např. uvidíte obrázek v „JPEG“ – protože většina nástrojů okolo JPEGu nese jeho jméno). Ale dost pochval, to důležité je, že v 7.1 naleznete o mnoho vylepšený memory management. To by mělo zvýšit robustnost serveru a eliminovat případné memory leaky. Abych neohříval jen cizí polívčičku ohřeji i tu svou, na zlepšení spořivosti paměti a checkeru memory leaků se podílela malou měrou i má osoba (méně humorné bylo, že právě tento checker pak odhalil chybu v mém vlastním kódu – aneb podle hesla „vše co řeknete/naprogramujete bude použito proti vám“ :-).
Pochopitelně bylo i mnoho dalších změn, kterých si uživatel všimne. Jednou, která by mohla při přechodu na 7.1 překvapit, je syntaxe pro dotazy nad tabulkami s definovanou dědičností. Zde se již nepoužívá TABNAME* pokud se má např. SELECT vykonat nad celou hierarchií tabulek, ale vše pracuje bez hvězdičky. Pokud chcete data jen z mateřské tabulky tak musíte použít před názvem tabulky slůvko ONLY. Pochopitelně pracuje i stará syntaxe, ale je nutné zavolat „SET SQL_Inheritance TO OFF“.
Nová je i možnost vytvořit novou DB jako kopii libovolné existující DB. Dříve se použila vždy pouze vzorová DB template1. V 7.1 můžete nastavit jako vzorovou i jinou DB pomoci:
CREATE DATABASE… WITH TEMPLATE…
Příkaz ALTER TABLE byl rozšířen o „OWNER TO“ možnost. O co se jedná je myslím zřejmé.
Novinkou je taktéž možnost SELECTu ze SELECTu, tedy na místo jména tabulky dát SELECT. Nejlépe to bude zřejmé z příkladu:
SELECT * FROM (SELECT data FROM thebest WHERE id = 1) AS topserver WHERE data LIKE ‚root.cz‘;
Aby nedošlo k omylu, nejedná se o klasický subselect, ten používá SELECT až v části WHERE. Kombinace FROM(SELECT) a WHERE .. (SELECT) muže vypadat např. takto:
SELECT * FROM (SELECT id, data FROM t1 WHERE id = 10) AS mytab WHERE data LIKE ‚root‘ AND id NOT IN (SELECT id FROM t2);
Pochopitelně uvedené ukázky jsou jen příklady a šlo by je napsat efektivněji bez použití FROM(SELECT).
Velmi příjemnou změnou je COPY WITH OID, tedy možnost nakopírovat data do/z DB včetně interních identifikačních čísel. V praxi to znamená, že např. DB obnovená ze zálohy bude stejná i co se týká jednotlivých oid řádek – tím se mírně rozšiřuje možnost ve vlastních aplikacích používat tyto identifikátory.
Z některých dalších novinek budou mít radost hlavně administrátoři SQL serveru. Byl kompletně přepsán program pg_dump a nyní dovoluje již i zálohování LO (large object). Dále pak tento program dostal bratříčka v podobě programu pg_restore. Jedná se taktéž o zálohovací nástroj, ale dovoluje ukládat data do vlastního formátu což narozdíl od čistě textového výstupu pg_dump umožňuje například nechat si vypsat co archiv obsahuje apod.
Protože svět OS není jen Linux a dobře napsaný kód v jazyce C je vcelku slušně portovatelný (ať si Sun a „teorie o Jávě“ říká co chce :-), tak i v oblasti portace na různé OS se dočkal PostgreSQL změn. Je zde podpora SGI, AIX, FreeBSD, Alpha, Darwin/MacOS X, IBM S/390, BeOS, Unixware, WinNT/Cygwin, Solaris. (Jen pro zajímavost – adresář se šablonami pro build system obsahuje soubory pro 21 různých OS)
Velmi pravděpodobně jsem zapomněl na některé zajímavé změny, ale nejlepším způsobem, jak zjistit, co je nového, bude přímo si PostgreSQL 7.1 vyzkoušet. Najdete jej naříklad zde.
ČLÁNKY DO MAILU