PostgreSQL

Uživatelé, kteří přechází z MySQL nebo Firebirdu, občas naráží na "inteligenci" PostgreSQL. V PostgreSQL není žádný způsob, jak jej donutit použít konkrétní index, a ještě se to považuje za výhodu. I když má PostgreSQL zřejmě nejpropracovanější optimalizaci ze všech open-source databází, mohou nastat situace, kdy optimalizace selže a sql dotazy trvají příliš dlouho. Kdy se tak stane a jak to řešit?

Rok intenzívního vývoje PostgreSQL vývojáři uzavřeli uvolněním beta verze 8.2. Na plnou verzi si ještě budeme muset počkat do Vánoc, nicméně už nyní si můžeme vytvořit představu o další verzi. Asi nejočekávanější podpora bitmapových indexů a editovatelných pohledů chybí. Neznamená to ovšem, že by se přechod na tuto verzi nevyplatil.

Zkuste si napsat vlastní debugger uložených procedur. Brzo zjistíte, že to není žádná legrace. Proč? Jednak debugger je typicky interaktivní aplikace, a prostředí uložených procedur se ani náhodou nedá označit jako interaktivní. Navíc se snažíte ladit kód, který je prováděn vzdáleně. Řeknu to rovnou, bez úpravy zdrojových kódů a rozšíření komunikačního protokolu nemáte šanci (jeden skoro skutečný debugger PL/pgSQL jsem už napsal). Když se ale smíříte s určitými omezeními a pokud použijete knihovnu orafce, je tu jistá naděje.

Rok 2005 se zapíše do historie, i do té open source databázové. Firebird2, MySQL5, PostgreSQL8 jsou systémy, které představují významný pokrok vůči předchozím verzím a s trochou nadsázky mohu upřímně napsat, že open source databáze dohonily komerční databázové systémy, které se ovšem zase dostaly někam jinam (kdo ale nepotřebuje OLAP, tak tomu by měly stávající open source systémy vyhovovat).

Článek na Root.cz mě vyprovokoval jednak k úvahám o smyslu srovnávacích testů, jednak k vlastnímu porovnání. Tyto analýzy nejsou tak úplně od věci. Nemají ale sloužit k jalové výměně názorů, který že systém je lepší, ale k diagnostice chyb. Hlavně těch mých. To, jak provádím testy, ukazuje na moje znalosti testovaných systémů, a pokud v testu dělám chybu, mám možnost, že mne na ni někdo upozorní a ukáže mi, jak ji nedělat. A ukáže to i ostatním.

Po vydaní novej verzie PostgreSQL 8.1 beta 2 som hľadal na nete nejaké benchmarky. Všetky testy, ktoré som našiel, však väčšinou porovnávali PostgreSQL ver. 7.4, pripadne 8.0, ale nie 8.1. Tak som sa rozhodol, že porovnám novú verziu s hneď dvoma databázami. S MySQL a Firebirdom.

Když jsem před několika lety psal první článek o PL/pgSQL, narazil jsem v dokumentaci na doporučení nepoužívat řetězec 'now' v tomto jazyce. Doporučení jsem akceptoval, vyzkoušel si, že to skutečně nefunguje, ale po pravdě řečeno moc jsem nechápal proč. Nejasně jsem si představoval, že se chybně přeloží do mezikódu (byte-code) i tato aktuální hodnota této pseudofunkce, což způsobí problém, na který upozorňovala dokumentace (čas vrácený řetězcem 'now' odpovídal překladu funkce).

Tímto článkem navazuji na svůj článek Krátce o PL/Perlu, který vyšel na Root.cz vloni v březnu. Zatímco vloni mne inspirovalo k sepsání článku úspěšné použití regulárních výrazů, inspirací k tomuto článku byl modul dbilink. Tento modul umožňuje přímý přístup z PostgreSQL do všech databází, ke kterým existuje DBI rozhraní.

Minulá verze PostgreSQL byla 7.4. Proč tedy nyní 8.0? Protože čas od času je vhodné změnit i to první číslo, aby nebylo smutné, že zůstává stále tou okoukanou sedmičkou, když přitom v kódu je tolik nových a neokoukaných novinek.

Při čtení tohoto seriálu jsem zjistil, že mi omylem vypadl díl věnovaný replikaci sekvencí. V dnešním dílu se na ně tedy podíváme.