PostgreSQL 19 (2026) - Historie editací

PavelStehule: /* SQL */

2026-07-18T03:58:33Z

SQL

← Starší verze		Verze z 18. 7. 2026, 03:58
Řádek 219:		Řádek 219:

	==SQL==		==SQL==
	<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:		<s><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 225:		Řádek 225:
	GROUP BY ALL;		GROUP BY ALL;
	</pre>		</pre>
	Tento zápis může ušetřit dost psaní, může to být také "tichý" zabiják výkonu. Čím více atributů je v klauzuli <code>GROUP BY</code>, tím je agregace pomalejší. Zápis <code>GROUP BY ALL</code> ještě není ve standardu, ale je standardizační komisí akceptován, a měl by být v některé další verzi ANSI/SQL.</p>		Tento zápis může ušetřit dost psaní, může to být také "tichý" zabiják výkonu. Čím více atributů je v klauzuli <code>GROUP BY</code>, tím je agregace pomalejší. Zápis <code>GROUP BY ALL</code> ještě není ve standardu, ale je standardizační komisí akceptován, a měl by být v některé další verzi ANSI/SQL.</p></s> revertovano

	<p>Počínaje Postgresem 19 už nebude možnost používat backlash jako escape symbol v řetězcích. Před 15 roky se přešlo na standardní chování (předtím se řetězce v Postgresu chovali stejně jako v Cčku), nicméně nestandardní chování bylo možné vynutit nastavením <code>standard_conforming_strings</code> na <code>off</code>. Mezi top vývojáři Postgresu je hodně velká averze k tzv kompatibility flagům (zmíněný flag nebyl výjimkou) (pozn. u komerčních databází jsou naopak kompatibility flagu standardem, a nejen u nich - např. MySQL). Nyní je tato možnost zrušena, a Cčkové stringy dostaneme pouze jen zápisem (jako tzv extended strings):		<p>Počínaje Postgresem 19 už nebude možnost používat backlash jako escape symbol v řetězcích. Před 15 roky se přešlo na standardní chování (předtím se řetězce v Postgresu chovali stejně jako v Cčku), nicméně nestandardní chování bylo možné vynutit nastavením <code>standard_conforming_strings</code> na <code>off</code>. Mezi top vývojáři Postgresu je hodně velká averze k tzv kompatibility flagům (zmíněný flag nebyl výjimkou) (pozn. u komerčních databází jsou naopak kompatibility flagu standardem, a nejen u nich - např. MySQL). Nyní je tato možnost zrušena, a Cčkové stringy dostaneme pouze jen zápisem (jako tzv extended strings):

PavelStehule: /* pg_plan_advice */

2026-06-22T15:38:03Z

pg_plan_advice

← Starší verze		Verze z 22. 6. 2026, 15:38
Řádek 146:		Řádek 146:

	==pg_plan_advice==		==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á. Robert 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: /* Administrace */

2026-06-18T17:38:16Z

Administrace

← Starší verze		Verze z 18. 6. 2026, 17:38
Řádek 42:		Řádek 42:
	Nová implementace by měla být řádově rychlejší.</p>		Nová implementace by měla být řádově rychlejší.</p>

	<s><p>Konečně se dotáhlo do konce začlenění podpory více formátů v příkazu <code>pg_dumpall</code>. Postgres má dva základní příkazy pro export (backup) - <code>pg_dump</code> a <code>pg_dumpall</code>. Historicky tyto příkazy podporovaly pouze <code>plain text</code> formát. Postupem času <code>pg_dump</code> získal možnost exportu do <code>custom</code>, <code>tar</code> a <code>dictionary</code> formátu plus import příkazem <code>pg_restore</code> umožňoval paralelní import více tabulek. <code>pg_dumpall</code> byl díky podpoře pouze SQL formátu dost omezený. To se nyní změnilo, a v <code>pg_dumpall</code> jsou podporovány všechny formáty, které podporuje <code>pg_dump</code>. Vypadá to trochu jako workaround. V případě, že se použije jiný než <code>plain text</code> (SQL) formát, tak se vyrobí adresář, který do podadresářů uloží výstup z <code>pg_dumpu</code>. <code>pg_restore</code> umí s touto adresářovou strukturou pracovat. Tato možnost se dostala už do 18tky, ale byla na poslední chvíli stažena.~~</p>~~</s> patch byl revertován.		<s><p>Konečně se dotáhlo do konce začlenění podpory více formátů v příkazu <code>pg_dumpall</code>. Postgres má dva základní příkazy pro export (backup) - <code>pg_dump</code> a <code>pg_dumpall</code>. Historicky tyto příkazy podporovaly pouze <code>plain text</code> formát. Postupem času <code>pg_dump</code> získal možnost exportu do <code>custom</code>, <code>tar</code> a <code>dictionary</code> formátu plus import příkazem <code>pg_restore</code> umožňoval paralelní import více tabulek. <code>pg_dumpall</code> byl díky podpoře pouze SQL formátu dost omezený. To se nyní změnilo, a v <code>pg_dumpall</code> jsou podporovány všechny formáty, které podporuje <code>pg_dump</code>. Vypadá to trochu jako workaround. V případě, že se použije jiný než <code>plain text</code> (SQL) formát, tak se vyrobí adresář, který do podadresářů uloží výstup z <code>pg_dumpu</code>. <code>pg_restore</code> umí s touto adresářovou strukturou pracovat. Tato možnost se dostala už do 18tky, ale byla na poslední chvíli stažena.</s> patch byl revertován.</p>

	<p>V <code>pg_rewind</code> zredukovalo kopírování WAL logů z nového primárního serveru na budovanou repliku a to tak, že se budou kopírovat pouze WAL logy vzniklé po rozpadu replikace. V mnoha scénářích se tím výrazně urychlí běh tohoto příkazu.</p>		<p>V <code>pg_rewind</code> zredukovalo kopírování WAL logů z nového primárního serveru na budovanou repliku a to tak, že se budou kopírovat pouze WAL logy vzniklé po rozpadu replikace. V mnoha scénářích se tím výrazně urychlí běh tohoto příkazu.</p>

PavelStehule: /* Administrace */

2026-06-18T17:37:41Z

Administrace

← Starší verze		Verze z 18. 6. 2026, 17:37
Řádek 42:		Řádek 42:
	Nová implementace by měla být řádově rychlejší.</p>		Nová implementace by měla být řádově rychlejší.</p>

	<p>Konečně se dotáhlo do konce začlenění podpory více formátů v příkazu <code>pg_dumpall</code>. Postgres má dva základní příkazy pro export (backup) - <code>pg_dump</code> a <code>pg_dumpall</code>. Historicky tyto příkazy podporovaly pouze <code>plain text</code> formát. Postupem času <code>pg_dump</code> získal možnost exportu do <code>custom</code>, <code>tar</code> a <code>dictionary</code> formátu plus import příkazem <code>pg_restore</code> umožňoval paralelní import více tabulek. <code>pg_dumpall</code> byl díky podpoře pouze SQL formátu dost omezený. To se nyní změnilo, a v <code>pg_dumpall</code> jsou podporovány všechny formáty, které podporuje <code>pg_dump</code>. Vypadá to trochu jako workaround. V případě, že se použije jiný než <code>plain text</code> (SQL) formát, tak se vyrobí adresář, který do podadresářů uloží výstup z <code>pg_dumpu</code>. <code>pg_restore</code> umí s touto adresářovou strukturou pracovat. Tato možnost se dostala už do 18tky, ale byla na poslední chvíli stažena.</p>		<s><p>Konečně se dotáhlo do konce začlenění podpory více formátů v příkazu <code>pg_dumpall</code>. Postgres má dva základní příkazy pro export (backup) - <code>pg_dump</code> a <code>pg_dumpall</code>. Historicky tyto příkazy podporovaly pouze <code>plain text</code> formát. Postupem času <code>pg_dump</code> získal možnost exportu do <code>custom</code>, <code>tar</code> a <code>dictionary</code> formátu plus import příkazem <code>pg_restore</code> umožňoval paralelní import více tabulek. <code>pg_dumpall</code> byl díky podpoře pouze SQL formátu dost omezený. To se nyní změnilo, a v <code>pg_dumpall</code> jsou podporovány všechny formáty, které podporuje <code>pg_dump</code>. Vypadá to trochu jako workaround. V případě, že se použije jiný než <code>plain text</code> (SQL) formát, tak se vyrobí adresář, který do podadresářů uloží výstup z <code>pg_dumpu</code>. <code>pg_restore</code> umí s touto adresářovou strukturou pracovat. Tato možnost se dostala už do 18tky, ale byla na poslední chvíli stažena.</p></s> patch byl revertován.

	<p>V <code>pg_rewind</code> zredukovalo kopírování WAL logů z nového primárního serveru na budovanou repliku a to tak, že se budou kopírovat pouze WAL logy vzniklé po rozpadu replikace. V mnoha scénářích se tím výrazně urychlí běh tohoto příkazu.</p>		<p>V <code>pg_rewind</code> zredukovalo kopírování WAL logů z nového primárního serveru na budovanou repliku a to tak, že se budou kopírovat pouze WAL logy vzniklé po rozpadu replikace. V mnoha scénářích se tím výrazně urychlí běh tohoto příkazu.</p>

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)