PostgreSQL

Práce s časovými zónami v PostgreSQL není úplně intuitivní a najde se pár temných zákoutí, která vás mohou potrápit. V článku probereme, jak se Postgres chová k typům určeným pro datum a čas.

Jak už to u každoročních vydání PostgreSQL bývá, k uživatelům se dostává mix několika větších nových vlastností doplněných desítkami menších novinek a vylepšení. Tým vývojářů je stabilní, stejně jako vývojový proces.

Je zajímavé, že chyby, které se často dělají při psaní funkcí v jazyku PL/pgSQL (PostgreSQL), jsou dost podobné, ne-li totožné jako chyby při používání PL/SQL (Oracle).

Po roce tu máme opět novou verzi PostgreSQL, a to verzi 10. Rok vývoje proběhl relativně v klidu – dodržel se časový plán, takže zůstalo dost času na stabilizaci a dokonce i na dovolené top vývojářů.

Posledního půl roku pracuji na migraci větší aplikace z Oracle do PostgreSQL. Jedná se o cca 300 000 řádek kódu – několika set tabulek a několik set pohledů. Logika je založená na uložených procedurách.

Ať už používáme jakoukoliv databázi, je nutné monitorovat jak databázi, tak databázový server. Dnes si ani nedovedu představit provoz nějaké náročnější aplikace bez základního monitoringu.

Jednou z klíčových výhod PL/pgSQL jsou kurzory. Dovolují vám procházet výsledek selectu a pomocí řídících příkazů jazyka modifikovat data a ty pak uložit do nějakého výsledku, nebo předat z funkce.

Oproti klasickým funkcím v PostgreSQL i procedurám v jiných jazycích stojí „Anonymous block“. Jedná se sérií deklarací a sekvencí procedurálních příkazů.

Při monitorování systému se snažíme o detekci úzkých hrdel. U systémů s extrémními problémy bez extrémní zátěže jsou problémy většinou už v samotném návrhu databáze a v návrhu dotazů.

Někdy je potřeba provést náročné výpočty, přesuny dat, nebo vytvořit obchodní pravidla. Tehdy sáhnete pravděpodobně po serverovém programování buďto přímo přes rozhraní, nebo po procedurálních jazycích.

Pokusím se vám ukázat, že konfigurace Postgresu je směšně jednoduchá. V první části se budu věnovat základnímu nastavení, které určuje, kolik zdrojů (RAM, IO) si může pro sebe vzít databáze.

Jak převést XML do reálného relačního světa? Podstatou jsou tabulky a relace, které existují hlavně formou cizí klíčů.

XML datové struktury byly původně vyvinuty, jako výměnný formát dat mezi systémy. Taky jsou důležité jako datová úložiště pro aplikace, které mají data hodně strukturovaná.

SQL dnes už umí více než spojování tabulek a poddotazy. Prostřednictvím analytických funkcí a rekurzivních dotazů se SQL dostává za rámec relačního modelu, což nám pomůže s řešením problémů.

Netradičně se letos dočkáme ještě jedné velké verze PostgreSQL. Ta představuje zásadní milník ve vývoji, uživatelé mají poprvé možnost využít více CPU pro spočítání jednoho SQL příkazu.

Který souborový systém mám použít pro produkční server, na kterém poběží PostgreSQL? Tuto otázku si klade řada správců serverů, ale ptají se na to i zákazníci nebo začátečníci rozhlížející se po světě serverů. Je v tom vůbec nějaký rozdíl? Vyplatí se řešit výhody různých systémů či jejich parametrů?

Na 9.5 se mi hůře hledá nějaké jedno zřetelné mediálně zajímavé téma. V předchozích verzích to nebyl problém – podpora JSONu, podpora index only scanu, LATERAL joinu, DDL triggerů, JSONB – to všechno jsou jasná výrazná témata. Na vývoji 9.5 vidím snahu o získání maxima ze stávajícího kódu.