PostgreSQL 19 (2026) - Historie editací

PavelStehule v 10. 5. 2026, 03:32

2026-05-10T03:32:56Z

← Starší verze		Verze z 10. 5. 2026, 03:32
Řádek 564:		Řádek 564:
	<p>V pohledu <code>pg_replication_slots</code> je nový sloupec <code>slotsync_skip_reason</code> popisující důvod, proč nebylo možné synchronizovat repliku. V tom případě bude obsahovat jednu z následujících hodnot: <code>wal_or_rows_removed</code>, <code>wal_not flushed</code>, <code>no_consistent_snapshot</code> nebo <code>slot_invalidated</code>.</p>		<p>V pohledu <code>pg_replication_slots</code> je nový sloupec <code>slotsync_skip_reason</code> popisující důvod, proč nebylo možné synchronizovat repliku. V tom případě bude obsahovat jednu z následujících hodnot: <code>wal_or_rows_removed</code>, <code>wal_not flushed</code>, <code>no_consistent_snapshot</code> nebo <code>slot_invalidated</code>.</p>

	<p>Pokud při registraci odběru nastavíme parametr <code>retain_dead_tuples</code> na <code>on</code> (výchozí nastavení je <code>off</code>), budou se detekovat kolize update-delete, kdy nedojde k update z důvodu smazaného řádku. Pozor, tato volba dočasně blokuje vakuování zrušených řádků (zvlášť pokud je replika nedostupná a nedochází k synchronizaci). Lze nastavit timeout <code>max_retention_duration</code>, samozřejmě ~~pak ovšem~~ může dojít ke kolizi update-delete. Bez detekce této kolize může dojít k tiché nekonzistenci obsahu napříč různými zdroji.</p>		<p>Pokud při registraci odběru nastavíme parametr <code>retain_dead_tuples</code> na <code>on</code> (výchozí nastavení je <code>off</code>), budou se detekovat kolize update-delete, kdy nedojde k update z důvodu smazaného řádku. Pozor, tato volba dočasně blokuje vakuování zrušených řádků (zvlášť pokud je replika nedostupná a nedochází k synchronizaci). Lze nastavit timeout <code>max_retention_duration</code>, samozřejmě po timeoutu může dojít k neidentifikovan0 kolizi update-delete. Bez detekce této kolize může dojít k tiché nekonzistenci obsahu napříč různými zdroji.</p>

	==Ostatní==		==Ostatní==
Řádek 709:		Řádek 709:
	<p>Každoročně dochází k čištění kódu. Občas se zruší podpora některé platformy. Výjimečně se přidá podpora nové platformy nebo jako v případě pg19 se vrátí podpora dříve odstraněné platformy (AIX - operační systém AIX přestal být podporovaný v pg17 díky nezájmu IBM. Pak se ale v IBM chytli za nos, dodali počítač do testovací farmy, a do AIXu přidali aktualizovaný software potřebný k buildu Postgresu). Další čistky v kódu lze provést přechodem na novější verzi programovacího jazyka - přechodem z C99 na C11 (bohužel to může znamenat, že starých platformách se nové verze Postgresu nepřeloží). Interní datový typ <code>Datum</code> až do předchozí verze byl 4bajtový na 32bitových platformách a 8bajtový na 64bitových platformách. Nově je 8bajtový na všech podporovaných platformách. Určitě nezanedbatelná část kódu se generuje z definičních souborů. Nově se z definic generuje kód definující konfigurační proměnné. Údržba, verzování, zajištění konzistence definičních souborů je násobně jednodušší než údržba adekvátního kódu v Cčku. Dynamická alokace paměti bude jednodušší díky funkcím <code>GetNamedDSA</code> a <code>GetNamedDSMSegment</code>. Dynamicky sdílenou paměť lze sledovat skrze pohled <code>pg_dsm_registry_allocations</code>.</p>		<p>Každoročně dochází k čištění kódu. Občas se zruší podpora některé platformy. Výjimečně se přidá podpora nové platformy nebo jako v případě pg19 se vrátí podpora dříve odstraněné platformy (AIX - operační systém AIX přestal být podporovaný v pg17 díky nezájmu IBM. Pak se ale v IBM chytli za nos, dodali počítač do testovací farmy, a do AIXu přidali aktualizovaný software potřebný k buildu Postgresu). Další čistky v kódu lze provést přechodem na novější verzi programovacího jazyka - přechodem z C99 na C11 (bohužel to může znamenat, že starých platformách se nové verze Postgresu nepřeloží). Interní datový typ <code>Datum</code> až do předchozí verze byl 4bajtový na 32bitových platformách a 8bajtový na 64bitových platformách. Nově je 8bajtový na všech podporovaných platformách. Určitě nezanedbatelná část kódu se generuje z definičních souborů. Nově se z definic generuje kód definující konfigurační proměnné. Údržba, verzování, zajištění konzistence definičních souborů je násobně jednodušší než údržba adekvátního kódu v Cčku. Dynamická alokace paměti bude jednodušší díky funkcím <code>GetNamedDSA</code> a <code>GetNamedDSMSegment</code>. Dynamicky sdílenou paměť lze sledovat skrze pohled <code>pg_dsm_registry_allocations</code>.</p>

	<p>Mám pocit, že vývoj Postgresu ještě víc zrychlil - je vidět mnohem víc patchů od lidí z Asie (dříve to bylo spíš jenom Japonsko), a o to víc se naráží na kapacitu committerů. Je to paradox, který nejde jednoduše řešit. Postgres je populární díky funkcionalitě a stabilitě. Stabilita je díky pečlivé práci commitetterů (důkladně se řeší každý řádek kódu). Díky popularitě je více programátorů, kteří píší více kódu, více patchů, ale committeři nestíhají, a tak patche zůstávají relativně dlouho ve frontě. Což frustruje programátory. Patch napíšete během měsíce, během měsíce se dá udělat finalizace a pár iterací s committerem, ale mezitím několik měsíců (v horším případě let (3 roky i v případě bezproblémového malého patche)), čekáte, až si na vás některý z committerů udělá čas. Celou dobu musíte udržovat patch v aplikovatelném stavu, musíte reagovat na případné diskuze, musíte sledovat vývoj a případně aktualizovat patch. Je to problém o kterém se ví, diskutuje se o něm, ale není úplně jasné, co by mělo být řešení. Minimálně se zlepšila evidence patchů, která pokrývá i automatické testování na několika různých platformách. Tady je velká klika, že Postgres má extenze. Neskutečně velký objem kódu (funkcionality) je dnes možné řešit skrz extenze mimo komunitu - což výrazně snižuje tlak na committery. V extenzích toho jde udělat hodně, bohužel, ne všechno. Na druhou stranu, extenze také nejsou bez rizika. Určitým způsobem zvyšují fragmentaci ekosystému Postgresu, který pak ztrácí přehlednost (plus ne všechny extenze jsou dostupné v cloudu). Zase, díky tomu je jádro Postgresu stále ještě rozumně velké. O Oracle se kolují zvěsti, že jádro má 14 miliónů řádek, Postgres pod 2 milióny. Náklady na údržbu Postgresu jsou výrazně menší. Kompilace zdrojáků je do 5 minut, regresní testy v největším rozsahu běží 15 minut. S tím ještě lze nějak rozumně pracovat. O Oracle jsem slyšel, že regresní testy běží den.</p>		<p>Mám pocit, že vývoj Postgresu ještě víc zrychlil - je vidět mnohem víc patchů od lidí z Asie (dříve to bylo spíš jenom Japonsko), a o to víc se naráží na kapacitu committerů. Je to paradox, který nejde jednoduše řešit. Postgres je populární díky funkcionalitě a stabilitě. Stabilita je díky pečlivé práci commitetterů (důkladně se řeší každý řádek kódu). Díky popularitě je více programátorů, kteří píší více kódu, více patchů, ale committeři nestíhají, a tak patche zůstávají relativně dlouho ve frontě. Což frustruje programátory. Patch napíšete během měsíce, během měsíce se dá udělat finalizace a pár iterací s committerem, ale mezitím několik měsíců (v horším případě let (3 roky i v případě bezproblémového malého patche)), čekáte, až si na vás některý z committerů udělá čas. Celou dobu musíte udržovat patch v aplikovatelném stavu, musíte reagovat na případné diskuze, musíte sledovat vývoj a případně aktualizovat patch. Je to problém o kterém se ví, diskutuje se o něm, ale není úplně jasné, co by mělo být řešení. Minimálně se zlepšila evidence patchů, která pokrývá i automatické testování na několika různých platformách. Tady je velká klika, že Postgres má extenze. Neskutečně velký objem kódu (funkcionality) je dnes možné řešit skrz extenze mimo komunitu - což výrazně snižuje tlak na committery. V extenzích toho jde udělat hodně, bohužel, ne všechno. Na druhou stranu, extenze také nejsou bez rizika. Určitým způsobem zvyšují fragmentaci ekosystému Postgresu, který pak ztrácí přehlednost (plus ne všechny extenze jsou dostupné v cloudu). Zase, díky tomu je jádro Postgresu stále ještě rozumně velké. O Oracle kolují zvěsti, že jádro má 14 miliónů řádek, Postgres pod 2 milióny. Náklady na údržbu Postgresu jsou výrazně menší. Kompilace zdrojáků je do 5 minut, regresní testy v největším rozsahu běží 15 minut. S tím ještě lze nějak rozumně pracovat. O Oracle jsem slyšel, že regresní testy běží den.</p>

	<p>Popularita Postgresu jde aktuálně až do absurdna. Z Linkedinu mám pocit, že začíná být přepostgresováno (samozřejmě z mé perspektivy a v mé bublině). Hromada příspěvků vygenerovaných AI jsou banality na úrovni žáka prvního stupně (Postgres má VACUUM, indexy jsou super, dotazy mohou být pomalé, atd atd). Doporučení typu - proč ne Redis, proč ne Elastic, na všechno použijte Postgres. Viděl jsem hromadu clickbaitových článků typu - multigenerační architektura Postgresu je tragická, ale s naší AI nebo s naším supportem nebudete mít problém, atd atd. Postgresu dnes rozumí každý, kdo dokáže do AI napsat Postgres. Měl jsem tu možnost vidět naprosto neadekvátní doporučení ohledně konfigurace (dnes nevíte jestli důvodem je neznalost autora nebo naopak jeho vychytralost a snaha o co nejvíc komentářů případně o troling). Historicky popularita Postgresu rostla ve stínu MySQL, Monga a dalších databází a roky byl Postgres ušetřený mediálního balastu. To bohužel už není pravda. Pořád platí, že Postgres je dobrá databáze, stabilní, relativně rychlá, která se ale rozhodně nehodí na vše. Má svoje limity, které je dobré znát, a rozhodně nemůže ve všech ohledech (ve větším rozsahu) nahradit Redis, MySQL nebo Mongo případně Kafku. To je nesmysl, a není to ani cílem komunity. Základem jakékoliv práce je znát limity, chování, a správně v souladu s celkem, používat správné nástroje.</p>		<p>Popularita Postgresu jde aktuálně až do absurdna. Z Linkedinu mám pocit, že začíná být přepostgresováno (samozřejmě z mé perspektivy a v mé bublině). Hromada příspěvků vygenerovaných AI jsou banality na úrovni žáka prvního stupně (Postgres má VACUUM, indexy jsou super, dotazy mohou být pomalé, atd atd). Doporučení typu - proč ne Redis, proč ne Elastic, na všechno použijte Postgres. Viděl jsem hromadu clickbaitových článků typu - multigenerační architektura Postgresu je tragická, ale s naší AI nebo s naším supportem nebudete mít problém, atd atd. Postgresu dnes rozumí každý, kdo dokáže do AI napsat Postgres. Měl jsem tu možnost vidět naprosto neadekvátní doporučení ohledně konfigurace (dnes nevíte jestli důvodem je neznalost autora nebo naopak jeho vychytralost a snaha o co nejvíc komentářů případně o troling). Historicky popularita Postgresu rostla ve stínu MySQL, Monga a dalších databází a roky byl Postgres ušetřený mediálního balastu. To bohužel už není pravda. Pořád platí, že Postgres je dobrá databáze, stabilní, relativně rychlá, která se ale rozhodně nehodí na vše. Má svoje limity, které je dobré znát, a rozhodně nemůže ve všech ohledech (ve větším rozsahu) nahradit Redis, MySQL nebo Mongo případně Kafku. To je nesmysl, a není to ani cílem komunity. Základem jakékoliv práce je znát limity, chování, a správně v souladu s celkem, používat správné nástroje.</p>

PavelStehule: /* Administrace */

2026-05-10T03:19:06Z

Administrace

← Starší verze		Verze z 10. 5. 2026, 03:19
Řádek 144:		Řádek 144:
	INSERT 0 1		INSERT 0 1
	</pre></p>		</pre></p>


	==pg_plan_advice==		==pg_plan_advice==

PavelStehule v 10. 5. 2026, 03:18

2026-05-10T03:18:17Z

Ukázat změny

PavelStehule v 10. 5. 2026, 03:15

2026-05-10T03:15:33Z

← Starší verze		Verze z 10. 5. 2026, 03:15
Řádek 3:		Řádek 3:
	<p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p>		<p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p>

	~~Administrace~~		==Administrace==
	====
	<p>Bloating tabulek může být problém. Skoro všude jsem se setkal se situací, kdy "mazací" skript přestal fungovat (z různých důvodů), přičemž se tato chyba detekovala příliš pozdě, kdy dotčené tabulky měly místo jednotek GB například desítky GB. To už musí zaúřadovat <code>VACUUM FULL</code>, což často znamená vynucenou plánovanou odstávku (kvůli držení exkluzivního zámku). Je to letitý problém, který zkušenější uživatelé řešili buďto pečlivějším monitoringem, v některých případech partišningem (partitioning), případně extenzemi <code>pg_repack</code> a <code>pg_squeeze</code>. Autor posledně jmenované extenze Tonda (Antonín Houska) spolu s Alvarem (Alvaro Herrera) poslední dva roky pracovali na integraci <code>pg_squeeze</code> do jádra Postgresu. Paradoxně příkaz, který bude provádět zdrcnutí tabulek, se bude jmenovat <code>REPACK</code>. Základem je logická replikace - zadaná tabulka se lokálně zreplikuje (vytvoří se její nová kopie, a tím se zbaví vnitřního neobsazeného místa). Co je zásadní, je možnost použít volbu <code>CONCURRENTLY</code>. S touto volbou příkaz nepoužije exkluzivní zámek. Tudíž je možné jej použít za provozu. Nutnou podmínkou je existence primárního klíče (a unikátního indexu).		<p>Bloating tabulek může být problém. Skoro všude jsem se setkal se situací, kdy "mazací" skript přestal fungovat (z různých důvodů), přičemž se tato chyba detekovala příliš pozdě, kdy dotčené tabulky měly místo jednotek GB například desítky GB. To už musí zaúřadovat <code>VACUUM FULL</code>, což často znamená vynucenou plánovanou odstávku (kvůli držení exkluzivního zámku). Je to letitý problém, který zkušenější uživatelé řešili buďto pečlivějším monitoringem, v některých případech partišningem (partitioning), případně extenzemi <code>pg_repack</code> a <code>pg_squeeze</code>. Autor posledně jmenované extenze Tonda (Antonín Houska) spolu s Alvarem (Alvaro Herrera) poslední dva roky pracovali na integraci <code>pg_squeeze</code> do jádra Postgresu. Paradoxně příkaz, který bude provádět zdrcnutí tabulek, se bude jmenovat <code>REPACK</code>. Základem je logická replikace - zadaná tabulka se lokálně zreplikuje (vytvoří se její nová kopie, a tím se zbaví vnitřního neobsazeného místa). Co je zásadní, je možnost použít volbu <code>CONCURRENTLY</code>. S touto volbou příkaz nepoužije exkluzivní zámek. Tudíž je možné jej použít za provozu. Nutnou podmínkou je existence primárního klíče (a unikátního indexu).
	<pre>		<pre>

PavelStehule v 10. 5. 2026, 03:15

2026-05-10T03:15:18Z

← Starší verze		Verze z 10. 5. 2026, 03:15
Řádek 4:		Řádek 4:

	Administrace		Administrace
	~~----~~		====
	<p>Bloating tabulek může být problém. Skoro všude jsem se setkal se situací, kdy "mazací" skript přestal fungovat (z různých důvodů), přičemž se tato chyba detekovala příliš pozdě, kdy dotčené tabulky měly místo jednotek GB například desítky GB. To už musí zaúřadovat <code>VACUUM FULL</code>, což často znamená vynucenou plánovanou odstávku (kvůli držení exkluzivního zámku). Je to letitý problém, který zkušenější uživatelé řešili buďto pečlivějším monitoringem, v některých případech partišningem (partitioning), případně extenzemi <code>pg_repack</code> a <code>pg_squeeze</code>. Autor posledně jmenované extenze Tonda (Antonín Houska) spolu s Alvarem (Alvaro Herrera) poslední dva roky pracovali na integraci <code>pg_squeeze</code> do jádra Postgresu. Paradoxně příkaz, který bude provádět zdrcnutí tabulek, se bude jmenovat <code>REPACK</code>. Základem je logická replikace - zadaná tabulka se lokálně zreplikuje (vytvoří se její nová kopie, a tím se zbaví vnitřního neobsazeného místa). Co je zásadní, je možnost použít volbu <code>CONCURRENTLY</code>. S touto volbou příkaz nepoužije exkluzivní zámek. Tudíž je možné jej použít za provozu. Nutnou podmínkou je existence primárního klíče (a unikátního indexu).		<p>Bloating tabulek může být problém. Skoro všude jsem se setkal se situací, kdy "mazací" skript přestal fungovat (z různých důvodů), přičemž se tato chyba detekovala příliš pozdě, kdy dotčené tabulky měly místo jednotek GB například desítky GB. To už musí zaúřadovat <code>VACUUM FULL</code>, což často znamená vynucenou plánovanou odstávku (kvůli držení exkluzivního zámku). Je to letitý problém, který zkušenější uživatelé řešili buďto pečlivějším monitoringem, v některých případech partišningem (partitioning), případně extenzemi <code>pg_repack</code> a <code>pg_squeeze</code>. Autor posledně jmenované extenze Tonda (Antonín Houska) spolu s Alvarem (Alvaro Herrera) poslední dva roky pracovali na integraci <code>pg_squeeze</code> do jádra Postgresu. Paradoxně příkaz, který bude provádět zdrcnutí tabulek, se bude jmenovat <code>REPACK</code>. Základem je logická replikace - zadaná tabulka se lokálně zreplikuje (vytvoří se její nová kopie, a tím se zbaví vnitřního neobsazeného místa). Co je zásadní, je možnost použít volbu <code>CONCURRENTLY</code>. S touto volbou příkaz nepoužije exkluzivní zámek. Tudíž je možné jej použít za provozu. Nutnou podmínkou je existence primárního klíče (a unikátního indexu).
	<pre>		<pre>

PavelStehule v 10. 5. 2026, 03:14

2026-05-10T03:14:51Z

← Starší verze		Verze z 10. 5. 2026, 03:14
Řádek 3:		Řádek 3:
	<p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p>		<p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p>

	~~<h3>~~Administrace~~</h3>~~		Administrace
			----
	<p>Bloating tabulek může být problém. Skoro všude jsem se setkal se situací, kdy "mazací" skript přestal fungovat (z různých důvodů), přičemž se tato chyba detekovala příliš pozdě, kdy dotčené tabulky měly místo jednotek GB například desítky GB. To už musí zaúřadovat <code>VACUUM FULL</code>, což často znamená vynucenou plánovanou odstávku (kvůli držení exkluzivního zámku). Je to letitý problém, který zkušenější uživatelé řešili buďto pečlivějším monitoringem, v některých případech partišningem (partitioning), případně extenzemi <code>pg_repack</code> a <code>pg_squeeze</code>. Autor posledně jmenované extenze Tonda (Antonín Houska) spolu s Alvarem (Alvaro Herrera) poslední dva roky pracovali na integraci <code>pg_squeeze</code> do jádra Postgresu. Paradoxně příkaz, který bude provádět zdrcnutí tabulek, se bude jmenovat <code>REPACK</code>. Základem je logická replikace - zadaná tabulka se lokálně zreplikuje (vytvoří se její nová kopie, a tím se zbaví vnitřního neobsazeného místa). Co je zásadní, je možnost použít volbu <code>CONCURRENTLY</code>. S touto volbou příkaz nepoužije exkluzivní zámek. Tudíž je možné jej použít za provozu. Nutnou podmínkou je existence primárního klíče (a unikátního indexu).		<p>Bloating tabulek může být problém. Skoro všude jsem se setkal se situací, kdy "mazací" skript přestal fungovat (z různých důvodů), přičemž se tato chyba detekovala příliš pozdě, kdy dotčené tabulky měly místo jednotek GB například desítky GB. To už musí zaúřadovat <code>VACUUM FULL</code>, což často znamená vynucenou plánovanou odstávku (kvůli držení exkluzivního zámku). Je to letitý problém, který zkušenější uživatelé řešili buďto pečlivějším monitoringem, v některých případech partišningem (partitioning), případně extenzemi <code>pg_repack</code> a <code>pg_squeeze</code>. Autor posledně jmenované extenze Tonda (Antonín Houska) spolu s Alvarem (Alvaro Herrera) poslední dva roky pracovali na integraci <code>pg_squeeze</code> do jádra Postgresu. Paradoxně příkaz, který bude provádět zdrcnutí tabulek, se bude jmenovat <code>REPACK</code>. Základem je logická replikace - zadaná tabulka se lokálně zreplikuje (vytvoří se její nová kopie, a tím se zbaví vnitřního neobsazeného místa). Co je zásadní, je možnost použít volbu <code>CONCURRENTLY</code>. S touto volbou příkaz nepoužije exkluzivní zámek. Tudíž je možné jej použít za provozu. Nutnou podmínkou je existence primárního klíče (a unikátního indexu).
	<pre>		<pre>
Řádek 146:		Řádek 147:


	~~<h3>~~pg_plan_advice~~</h3>~~		pg_plan_advice
			----
	<p>Až doposud uživatelé Postgresu neměli moc možností, jak ovlivnit generování prováděcích plánů. Hinty ve stylu Oracle byly a jsou z historických důvodů tabu (jsou implementovány extenzí [https://github.com/ossc-db/pg_hint_plan pg_hint_plan]). Uživatel měl pouze možnost penalizace metod executoru - např. <code>enable_nestloop</code> nebo <code>enable_indexscan</code> nastavením na <code>off</code>. Tato penalizace je ale dost hrubá, a neumožňuje jemné ovlivnění plánovače. Přesto se používala a používá. Rober Haas napsal dvě extenze [https://www.postgresql.org/docs/devel/pgplanadvice.html <code>pg_plan_advice</code>] a [https://www.postgresql.org/docs/devel/pgstashadvice.html code>pg_stash_advice</code>]. Prvně zmíněná extenze umožňuje definovat jakási doporučení, která by měl planner respektovat. Pro každý plán lze zpětně dogenerovat tato doporučení:		<p>Až doposud uživatelé Postgresu neměli moc možností, jak ovlivnit generování prováděcích plánů. Hinty ve stylu Oracle byly a jsou z historických důvodů tabu (jsou implementovány extenzí [https://github.com/ossc-db/pg_hint_plan pg_hint_plan]). Uživatel měl pouze možnost penalizace metod executoru - např. <code>enable_nestloop</code> nebo <code>enable_indexscan</code> nastavením na <code>off</code>. Tato penalizace je ale dost hrubá, a neumožňuje jemné ovlivnění plánovače. Přesto se používala a používá. Rober Haas napsal dvě extenze [https://www.postgresql.org/docs/devel/pgplanadvice.html <code>pg_plan_advice</code>] a [https://www.postgresql.org/docs/devel/pgstashadvice.html <code>pg_stash_advice</code>]. Prvně zmíněná extenze umožňuje definovat jakási doporučení, která by měl planner respektovat. Pro každý plán lze zpětně dogenerovat tato doporučení:
	<pre>		<pre>
	EXPLAIN (PLAN_ADVICE)		EXPLAIN (PLAN_ADVICE)

PavelStehule v 10. 5. 2026, 03:12

2026-05-10T03:12:35Z

← Starší verze		Verze z 10. 5. 2026, 03:12
Řádek 1:		Řádek 1:
	Autor: Pavel Stěhule		<i>Autor: Pavel Stěhule</i>

	~~<h2>PostgreSQL 19 (2026)~~</h2>


	<p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p>		<p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p>
Řádek 20:		Řádek 17:
	<p>Možná jste si všimli, že dotaz běžící pod příkazem <code>EXPLAIN ANALYZE</code> je výrazně pomalejší. Důvodem je měření času - executor, v tomto režimu, neustále poptává aktuální čas, a to má brutální režii. U větších dotazů se vyplatí použít volbu <code>TIMING OFF</code>. V 19 na x86 se místo systémového času použíjí takty CPU. Je to výrazně rychlejší - zatímco na osmnáctce mi jednoduchý testovací dotaz běžel 2.5x pomalejší v explainu, na devatenáctce pouze 1.5x pomaleji.</p>		<p>Možná jste si všimli, že dotaz běžící pod příkazem <code>EXPLAIN ANALYZE</code> je výrazně pomalejší. Důvodem je měření času - executor, v tomto režimu, neustále poptává aktuální čas, a to má brutální režii. U větších dotazů se vyplatí použít volbu <code>TIMING OFF</code>. V 19 na x86 se místo systémového času použíjí takty CPU. Je to výrazně rychlejší - zatímco na osmnáctce mi jednoduchý testovací dotaz běžel 2.5x pomalejší v explainu, na devatenáctce pouze 1.5x pomaleji.</p>

	<p>Malou velkou změnou je vypnutí JIT ve výchozí konfiguraci. JIT se objevil v Postgresu 11, a v Postgresu 12 byl zapnutý ve výchozí konfiguraci. Bohužel se zjistilo, že většině uživatelů, kteří Postgres používají pro OLTP, dělá víc škody než užitku. Došlo to až do stavu, kdy se uživatelům doporučovalo, neoficiálně, po instalaci JIT vypnout. Je tam víc problémů. <code>clang</code>, na kterém je to postavené, v novějších verzích kompiluje lépe, ale pomaleji. Existují alternativní implementace JIT, ale všechny jsou více než méně experimentální. Druhým problémem je model, na jehož základě se JIT aktivuje. Tento model jednak nedokáže dobře odhadnout náročnost "jitifikace - inliningu, a navíc je citlivý na přestřelení odhadu počtu řádek. Ohledně modelu a citlivosti na odhady pochybuji, že se dá něco dělat. Alternativní implementace JIT mají výrazně nižší režii. Přijde mi to ale jako slepá cesta. Budoucnost vidím v integraci vektorového executoru a vektorových funkcí (tak jak to používá ~~<a href="~~https://duckdb.org/">DuckDB~~</a>~~). Může to znamenat, že Postgres bude mít duální implementace funkcí (pro skalární parametr, a pro vektor parametrů).</p>		<p>Malou velkou změnou je vypnutí JIT ve výchozí konfiguraci. JIT se objevil v Postgresu 11, a v Postgresu 12 byl zapnutý ve výchozí konfiguraci. Bohužel se zjistilo, že většině uživatelů, kteří Postgres používají pro OLTP, dělá víc škody než užitku. Došlo to až do stavu, kdy se uživatelům doporučovalo, neoficiálně, po instalaci JIT vypnout. Je tam víc problémů. <code>clang</code>, na kterém je to postavené, v novějších verzích kompiluje lépe, ale pomaleji. Existují alternativní implementace JIT, ale všechny jsou více než méně experimentální. Druhým problémem je model, na jehož základě se JIT aktivuje. Tento model jednak nedokáže dobře odhadnout náročnost "jitifikace - inliningu, a navíc je citlivý na přestřelení odhadu počtu řádek. Ohledně modelu a citlivosti na odhady pochybuji, že se dá něco dělat. Alternativní implementace JIT mají výrazně nižší režii. Přijde mi to ale jako slepá cesta. Budoucnost vidím v integraci vektorového executoru a vektorových funkcí (tak jak to používá [https://duckdb.org/ DuckDB]). Může to znamenat, že Postgres bude mít duální implementace funkcí (pro skalární parametr, a pro vektor parametrů).</p>

	<p>Nově lze vytvořit replikační slot pro logickou replikaci, bez nutnosti mít konfiguraci <code>wal_level=logical</code>. Postačuje nastavení <code>replica</code>, což je výchozí nastavení. Jakmile je logický replikační slot aktivní, interně se úroveň zápisu do transakčního logu nastaví na <code>logical</code>. Jaký je aktuální stav zjistíte v konfigurační proměnné <code>effective_wal_level</code>.</p>		<p>Nově lze vytvořit replikační slot pro logickou replikaci, bez nutnosti mít konfiguraci <code>wal_level=logical</code>. Postačuje nastavení <code>replica</code>, což je výchozí nastavení. Jakmile je logický replikační slot aktivní, interně se úroveň zápisu do transakčního logu nastaví na <code>logical</code>. Jaký je aktuální stav zjistíte v konfigurační proměnné <code>effective_wal_level</code>.</p>
Řádek 151:		Řádek 148:
	<h3>pg_plan_advice</h3>		<h3>pg_plan_advice</h3>

	<p>Až doposud uživatelé Postgresu neměli moc možností, jak ovlivnit generování prováděcích plánů. Hinty ve stylu Oracle byly a jsou z historických důvodů tabu (jsou implementovány extenzí ~~<a href="~~https://github.com/ossc-db/pg_hint_plan">pg_hint_plan~~</a>~~). Uživatel měl pouze možnost penalizace metod executoru - např. <code>enable_nestloop</code> nebo <code>enable_indexscan</code> nastavením na <code>off</code>. Tato penalizace je ale dost hrubá, a neumožňuje jemné ovlivnění plánovače. Přesto se používala a používá. Rober Haas napsal dvě extenze ~~<a href="~~https://www.postgresql.org/docs/devel/pgplanadvice.html"><code>pg_plan_advice</code>~~</a> a <~~a ~~href="~~https://www.postgresql.org/docs/devel/pgstashadvice.html~~"><~~code>pg_stash_advice</code>~~</a>~~. Prvně zmíněná extenze umožňuje definovat jakási doporučení, která by měl planner respektovat. Pro každý plán lze zpětně dogenerovat tato doporučení:		<p>Až doposud uživatelé Postgresu neměli moc možností, jak ovlivnit generování prováděcích plánů. Hinty ve stylu Oracle byly a jsou z historických důvodů tabu (jsou implementovány extenzí [https://github.com/ossc-db/pg_hint_plan pg_hint_plan]). Uživatel měl pouze možnost penalizace metod executoru - např. <code>enable_nestloop</code> nebo <code>enable_indexscan</code> nastavením na <code>off</code>. Tato penalizace je ale dost hrubá, a neumožňuje jemné ovlivnění plánovače. Přesto se používala a používá. Rober Haas napsal dvě extenze [https://www.postgresql.org/docs/devel/pgplanadvice.html <code>pg_plan_advice</code>] a [https://www.postgresql.org/docs/devel/pgstashadvice.html code>pg_stash_advice</code>]. Prvně zmíněná extenze umožňuje definovat jakási doporučení, která by měl planner respektovat. Pro každý plán lze zpětně dogenerovat tato doporučení:
	<pre>		<pre>
	EXPLAIN (PLAN_ADVICE)		EXPLAIN (PLAN_ADVICE)
Řádek 224:		Řádek 221:

	<h3>SQL</h3>		<h3>SQL</h3>
	<p><code>GROUP BY ALL</code> je syntaxe, kterou postres přejímá z analytických databází (zde to snad byla ~~<a href="~~https://duckdb.org/2022/05/04/friendlier-sql#group-by-all">DuckDB~~</a>~~). Pokud se použije tento zápis, tak se automaticky agreguje podle všech sloupců, které nejsou v agregační funkci:		<p><code>GROUP BY ALL</code> je syntaxe, kterou postres přejímá z analytických databází (zde to snad byla [https://duckdb.org/2022/05/04/friendlier-sql#group-by-all DuckDB]). Pokud se použije tento zápis, tak se automaticky agreguje podle všech sloupců, které nejsou v agregační funkci:
	<pre>		<pre>
	SELECT sum(pocet_zen + pocet_muzu), okresy.id, okresy.nazev		SELECT sum(pocet_zen + pocet_muzu), okresy.id, okresy.nazev
Řádek 255:		Řádek 252:

	<h3>SQL/PGQ</h3>		<h3>SQL/PGQ</h3>
	<p>V tomto případě PG není častým prefixem symbolizujícím Postgres (a Q jako queue), ale Property Graph Queries. Počínaje podporou neatomických datových typů v SQL:2000, přes podporu XML v SQL:2003 se standard rozšířil nad rámec čistě relačních databází (stejně ale už dříve existovala kritika SQL z pohledu čistoty od relačních dogmatiků). Standard SQL:2023 (ISO/IEC 9075-16:2023) SQL rozšiřuje o podporu grafových databází, které mají svůj vlastní datový model odlišný od relačního modelu. Přijde mi to jako dost odvážný krok (a ještě teď tomu nemohu úplně uvěřit). Zatím existovala zřetelná jednota mezi SQL a relačním modelem. Od nové části standardu se očekává, že pomůže s přehlednějším zápisem určitých dotazů, které se až doposud řešily pomocí rekurze. Přiznám se, že zápis dotazu v PGQ (využívajícího ascii art) mi přijde hodně cizí (možná zažívám pocity programátora v Cobolu, když se poprvé podíval na SQL. Osobně mi to nesedí - reprezentaci znalostí ve formátu grafu jsem nikdy nemusel (vím, že je to jen jiná reprezentace téhož)). Row pattern recognition z roku SQL:2016 toho také nemá s relačními databázemi moc společného, takže to takové překvapení není. Práce na této části standardu začaly v roce 2017 (a integrovaly se prvky jazyka ~~<a href="~~https://neo4j.com/docs/cypher-manual/current/introduction/cypher-overview/">Cypher~~</a>~~ (Neo4j) a ~~<a href="~~https://docs.oracle.com/en/database/oracle/property-graph/20.4/spgdg/property-graph-query-language-pgql.html#GUID-301FF092-1A07-43D2-91E5-0C5AFF3467CC">PGQL~~</a>~~ (Oracle)).</p>		<p>V tomto případě PG není častým prefixem symbolizujícím Postgres (a Q jako queue), ale Property Graph Queries. Počínaje podporou neatomických datových typů v SQL:2000, přes podporu XML v SQL:2003 se standard rozšířil nad rámec čistě relačních databází (stejně ale už dříve existovala kritika SQL z pohledu čistoty od relačních dogmatiků). Standard SQL:2023 (ISO/IEC 9075-16:2023) SQL rozšiřuje o podporu grafových databází, které mají svůj vlastní datový model odlišný od relačního modelu. Přijde mi to jako dost odvážný krok (a ještě teď tomu nemohu úplně uvěřit). Zatím existovala zřetelná jednota mezi SQL a relačním modelem. Od nové části standardu se očekává, že pomůže s přehlednějším zápisem určitých dotazů, které se až doposud řešily pomocí rekurze. Přiznám se, že zápis dotazu v PGQ (využívajícího ascii art) mi přijde hodně cizí (možná zažívám pocity programátora v Cobolu, když se poprvé podíval na SQL. Osobně mi to nesedí - reprezentaci znalostí ve formátu grafu jsem nikdy nemusel (vím, že je to jen jiná reprezentace téhož)). Row pattern recognition z roku SQL:2016 toho také nemá s relačními databázemi moc společného, takže to takové překvapení není. Práce na této části standardu začaly v roce 2017 (a integrovaly se prvky jazyka [https://neo4j.com/docs/cypher-manual/current/introduction/cypher-overview/ Cypher] (Neo4j) a [https://docs.oracle.com/en/database/oracle/property-graph/20.4/spgdg/property-graph-query-language-pgql.html#GUID-301FF092-1A07-43D2-91E5-0C5AFF3467CC PGQL] (Oracle)).</p>

	<p>Základem grafových databází je graf skládající se z uzlů a hran. Ka každému uzlu i hraně mohou být přiřazeny atributy (properties). Hrany mohou být orientované i neorientované. Standard pro takové grafy používá termín Property Graphs. Graf se definuje příkazem <code>CREATE PROPERTY GRAPH</code> a je to určitá forma pohledu. Přesto, že jsem zkoušel poměrně triviální příklad, nebylo pro mne intuitivní napsat SQL/PGQ dotaz. Pro uživatele bez zkušenosti s Neo4j nebo jinou grafovou databází budou začátky s SQL/PGQ dost bolestivé. V tuto chvíli (duben 2026) ještě není hotová dokumentace. Je možné, že se díky integraci SQL/PGQ do Postgresu setkám s grafovými databázemi častěji (SQL/PGQ je podporováno v DuckDB a v Oracle):		<p>Základem grafových databází je graf skládající se z uzlů a hran. Ka každému uzlu i hraně mohou být přiřazeny atributy (properties). Hrany mohou být orientované i neorientované. Standard pro takové grafy používá termín Property Graphs. Graf se definuje příkazem <code>CREATE PROPERTY GRAPH</code> a je to určitá forma pohledu. Přesto, že jsem zkoušel poměrně triviální příklad, nebylo pro mne intuitivní napsat SQL/PGQ dotaz. Pro uživatele bez zkušenosti s Neo4j nebo jinou grafovou databází budou začátky s SQL/PGQ dost bolestivé. V tuto chvíli (duben 2026) ještě není hotová dokumentace. Je možné, že se díky integraci SQL/PGQ do Postgresu setkám s grafovými databázemi častěji (SQL/PGQ je podporováno v DuckDB a v Oracle):
Řádek 718:		Řádek 715:

	<p>Popularita Postgresu jde aktuálně až do absurdna. Z Linkedinu mám pocit, že začíná být přepostgresováno (samozřejmě z mé perspektivy a v mé bublině). Hromada příspěvků vygenerovaných AI jsou banality na úrovni žáka prvního stupně (Postgres má VACUUM, indexy jsou super, dotazy mohou být pomalé, atd atd). Doporučení typu - proč ne Redis, proč ne Elastic, na všechno použijte Postgres. Viděl jsem hromadu clickbaitových článků typu - multigenerační architektura Postgresu je tragická, ale s naší AI nebo s naším supportem nebudete mít problém, atd atd. Postgresu dnes rozumí každý, kdo dokáže do AI napsat Postgres. Měl jsem tu možnost vidět naprosto neadekvátní doporučení ohledně konfigurace (dnes nevíte jestli důvodem je neznalost autora nebo naopak jeho vychytralost a snaha o co nejvíc komentářů případně o troling). Historicky popularita Postgresu rostla ve stínu MySQL, Monga a dalších databází a roky byl Postgres ušetřený mediálního balastu. To bohužel už není pravda. Pořád platí, že Postgres je dobrá databáze, stabilní, relativně rychlá, která se ale rozhodně nehodí na vše. Má svoje limity, které je dobré znát, a rozhodně nemůže ve všech ohledech (ve větším rozsahu) nahradit Redis, MySQL nebo Mongo případně Kafku. To je nesmysl, a není to ani cílem komunity. Základem jakékoliv práce je znát limity, chování, a správně v souladu s celkem, používat správné nástroje.</p>		<p>Popularita Postgresu jde aktuálně až do absurdna. Z Linkedinu mám pocit, že začíná být přepostgresováno (samozřejmě z mé perspektivy a v mé bublině). Hromada příspěvků vygenerovaných AI jsou banality na úrovni žáka prvního stupně (Postgres má VACUUM, indexy jsou super, dotazy mohou být pomalé, atd atd). Doporučení typu - proč ne Redis, proč ne Elastic, na všechno použijte Postgres. Viděl jsem hromadu clickbaitových článků typu - multigenerační architektura Postgresu je tragická, ale s naší AI nebo s naším supportem nebudete mít problém, atd atd. Postgresu dnes rozumí každý, kdo dokáže do AI napsat Postgres. Měl jsem tu možnost vidět naprosto neadekvátní doporučení ohledně konfigurace (dnes nevíte jestli důvodem je neznalost autora nebo naopak jeho vychytralost a snaha o co nejvíc komentářů případně o troling). Historicky popularita Postgresu rostla ve stínu MySQL, Monga a dalších databází a roky byl Postgres ušetřený mediálního balastu. To bohužel už není pravda. Pořád platí, že Postgres je dobrá databáze, stabilní, relativně rychlá, která se ale rozhodně nehodí na vše. Má svoje limity, které je dobré znát, a rozhodně nemůže ve všech ohledech (ve větším rozsahu) nahradit Redis, MySQL nebo Mongo případně Kafku. To je nesmysl, a není to ani cílem komunity. Základem jakékoliv práce je znát limity, chování, a správně v souladu s celkem, používat správné nástroje.</p>
			----------
			<DPL>category=Verze PostgreSQL</DPL>
			[[Category:Články]]
			[[Category:Verze PostgreSQL]]

PavelStehule: založena nová stránka s textem „Autor: Pavel Stěhule

PostgreSQL 19 (2026)

O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.

Administrace

Bloating tabule…“

2026-05-10T03:08:40Z

založena nová stránka s textem „Autor: Pavel Stěhule <h2>PostgreSQL 19 (2026)</h2> <p>O předchozích verzích jsem napsal, že změny byly primárně interní. Z pohledu uživatele, který chce vidět novou SQL syntax, se toho v posledních verzích moc nestalo. Devatenáctka je jiná. Tam je viditelných změn opravdu hodně. Jako každý rok - nová verze je pelmel nových funkcí a různých vylepšení menších nebo větších.</p> <h3>Administrace</h3> <p>Bloating tabule…“

Ukázat změny