Co nového v PostgreSQL 8.0?

Native Windows port – vážně vám neřeknu, jaké to je, ale je jisté, že je to zde. A nebylo to snadné. Nativní port znamená možnost běhu bez speciálních unixových berliček, jako je cygwin. Uživatelům by měla udělat radost i existence instalačního programu. Mate-li vážný důvod pro práci v tomto OS (například pan RMS v těchto případech raději nepracuje), tak již můžete i s PostgreSQL.

Určitě velmi příjemnou novinkou jsou savepoints, které jsou někdy nazývány také nested transaction. Savepoint vám umožní definovat v transakci místo, kam se má v případě nezdaru vrátit. Nemusíte tak přijít o všechny změny, které jste v transakci udělali, ale můžete se pokusit chybu napravit a dotáhnout načatou transakci až do zdárného konce. Savepointy jsou pojmenovávány a může jich být v transakci definováno více. Pak se lze pomocí příkazu ROLLBACK TO SAVEPOINT <name> vrátit v transakci do vámi pojmenovaného bodu.

Každý, kdo má opravdu velkou databázi, nebo databázi, ve které se data nepřetržitě mění, ví, že kvalitní zálohování je problém. Konečné řešení je on-line backup s podporou „Point-In-Time Recovery“. Řešení pro zálohování je to elegantní a snadné a hlavně se zálohují jen změny. Ve své podstatě se jedná o zálohování transakčního logu, který obsahuje vše, co se na serveru děje. Nastavení je poměrně snadné. V konfiguraci serveru se definuje příkaz, který má server zavolat, má-li nějaká data pro zazálohování (jedná se o 16Mb soubory). Je jen na vás, kam tyto soubory budete přesouvat (páska, DVD, NFS, jiný disk apod.). Obnova se děje tak, že serveru definujete naopak příkaz, který mu vrací tyto zazálohované soubory. Vše je pěkně popsáno v dokumentaci.

Tuneři a administrátoři určitě ocení možnost definovat, kam ukládat soubory tabulek a indexů. A k tomu slouží konečně implementovaný tablespace. V současné době je tablespace podporován jen na OS, které podporují symlinky. Určitě zajímavou vlastností příkazu CREATE TABLESPACE je možnost definovat, komu bude tablespace patřit a kdo si tam může definovat další objekty (včetně databází). Tento uživatel nemusí být superuživatel. Znamená to možnost delegace práv superuživatele na jiné uživatele v rámci přesně vymezeného prostoru. To je pochopitelně velkým přínosem v prostředí, kde se o jeden DB stroj dělí několik samostatných projektů (třeba hosting DB serveru).

Evergreen v podobě příkazu ALTER TABLE nemůže chybět ani v této release. Byla mu dodělána možnost změny datového typu u sloupce tabulky.

Pokud jste strávili nějaký významnější čas optimalizováním velikosti sdílené buffer cache, bude vhodné si tuto záležitost zopakovat, protože byl změněn algoritmus hledání a organizace záznamů v této cache. Pro ty, kde nevědí, co je to za cache – tak ta, která slouží k uchovávání přečtených a modifikovaných bloků dat z disku. S tím přímo souvisí další výkonnostní změna, a to je nový samostatný proces běžící na serveru, který zapisuje modifikovaná data na disk. Ve výstupu programu ps ho poznáte podle jména postgres: writer process. Jeho existenci by mohli pocítit hlavně majitelé strojů s více CPU.

Ten, kdo zapisuje něco složitějšího a rozsáhlejšího do SQL dotazů, určitě bude mít radost z dollar-quoted stringů. Klasický způsob, jak v SQL zapsat řetězec, je:

'It\'s the best database server.'

Nově můžete zapsat:

$$It's the best database server.$$

nebo:

$foo$It's best database server.$foo$

kde „foo“ je vámi vytvořený tag. Určitě si řeknete, k čemu taková šílenost, ale pokud budete psát mnohařádkovou SQL funkci s mnoha uvozovkami, jistě oceníte možnost zápisu bez nutnosti escapování nějakých kontrolních znaků (uvnitř řetězce může být použit i dolar).

Hlavně v komunikaci s kancelářským software by mohla být výhoda v podpoře CSV (comma-separated-value) formátu u COPY příkazu. Vaše datové soubory se tak mohou tetelit množstvím uvozovek a čárek.

Několika vnitřních změn doznal optimalizer/planner v práci s indexy. Verze 8.0 se snaží maximálně využívat existující indexy, a to i tehdy, když se definice indexu úplně nekryje se zpracovávaným dotazem, a to jak svým obsahem (ve smyslu použití jen části indexu apod.), tak datovým typem. Taktéž přínosné je používání indexů pro hledání záznamů dle podmínky s OR operátorem.

Pokud používáte typ CHAR() – v PostgreSQL to nemá výkonnostní efekt oproti VARCHAR() – tak určitě důležitou změnou je, že funkce length() již nezahrnuje do vrácené hodnoty prázdné místo, které chybí do délky definované v CHAR() v definici sloupce. Vrácena je jen délka reálných dat.

A pokud používáte celkem sexy typ BIT(n), tak od této verze je při přetypování z INT bráno ‚n‘ bitů z pravé strany na rozdíl od předchozího používání bitů zleva. Pokud tomu všemu nerozumíte, znamená to pouze, že BIT je pro vás zbytečný a postačující je pro vás armáda sloupců typu BOOL ve vašich tabulkách.

Určitě důležitou změnou, ke které dojde ve verzi následující, ale je vhodné se na ni připravit již nyní, je používání OID vnitřního identifikátoru záznamů v tabulce. Má-li tabulka (ne)obsahovat OID, je nutné to při jejím vytvoření definovat pomocí (WITHOUT) WITH OID. Od verze 8.1 bude WITHOUT OID default! Používá-li vaše aplikace na něco OID, připravte se na to raději předem.

Pokud vás život dostal do situace, že používáte příkaz LOCK, byla přidána neblokující varianta LOCK NOWAIT, která, nelze-li ihned uzamknout tabulku, skončí chybovou hláškou. Podobně se bude chovat v release 8.1 i příkaz SELECT FOR UPDATE NOWAIT.

Změn je pochopitelně mnohem a mnohem více, ale na jejich popis zde není prostor. Bude proto lepší si PostgreSQL 8.0 nainstalovat a začít používat.