PostgreSQL 19 (2026) - Historie editací

PavelStehule: /* Administrace */

2026-09-16T09:44:22Z

Administrace

← Starší verze		Verze z 16. 9. 2026, 09:44
Řádek 21:		Řádek 21:
	<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>

	<p>Další bombou je možnost zapínat nebo vypínat kontrolní součty (na úrovni datových stránek) za běhu. Kontrolní součty jsou v Postgresu už relativně dlouho, a ačkoliv na dnešním hardware je jejich režie zanedbatelná, tak určitě bude dost databází, kde nebudou zapnuté. Zapnutí kontrolních součtů vyžadovalo odstávku úměrnou velikosti databáze. Navíc se silně doporučuje po zapnutí součtů znovu zreplikovat všechny fyzické repliky. Výhodou je diagnostika, možnost identifikovat poškozené stránky (a přeskočit je), možnost vyrobit replikovaný server ze starého primárního příkazem <code>pg_rewind</code>. Naplánovat a provést delší odstávku někde nemusí být jednoduché (nebo to může být skoro nemožné). U jednoho mého klienta zapnutí kontrolních součtů na cca 2TB databázi trvalo cca 2 hodiny (na vlastním hardware z roku 2025). Zapnutí se provede voláním funkce <code>pg_enable_data_checksums</code>. Nastavením volitelných parametrů lze běh funkce zpomalit, tak aby nepřetěžovala IO. Vypnutí provede funkce <code>pg_disable_data_checksums</code>. Stav procesu můžeme vidět v pohledu <code>pg_stat_progress_data_checksums</code>.</p>		<p>revertnuto<s>Další bombou je možnost zapínat nebo vypínat kontrolní součty (na úrovni datových stránek) za běhu. Kontrolní součty jsou v Postgresu už relativně dlouho, a ačkoliv na dnešním hardware je jejich režie zanedbatelná, tak určitě bude dost databází, kde nebudou zapnuté. Zapnutí kontrolních součtů vyžadovalo odstávku úměrnou velikosti databáze. Navíc se silně doporučuje po zapnutí součtů znovu zreplikovat všechny fyzické repliky. Výhodou je diagnostika, možnost identifikovat poškozené stránky (a přeskočit je), možnost vyrobit replikovaný server ze starého primárního příkazem <code>pg_rewind</code>. Naplánovat a provést delší odstávku někde nemusí být jednoduché (nebo to může být skoro nemožné). U jednoho mého klienta zapnutí kontrolních součtů na cca 2TB databázi trvalo cca 2 hodiny (na vlastním hardware z roku 2025). Zapnutí se provede voláním funkce <code>pg_enable_data_checksums</code>. Nastavením volitelných parametrů lze běh funkce zpomalit, tak aby nepřetěžovala IO. Vypnutí provede funkce <code>pg_disable_data_checksums</code>. Stav procesu můžeme vidět v pohledu <code>pg_stat_progress_data_checksums</code>.</p></s>

	<p>Snad se už konečně vyřešil problém s upgradem databází obsahující extrémně velký počet LO (large objects). Nově binární upgrade (<code>pg_upgrade</code>) použije pro export metadat LO příkaz <code>COPY</code> místo původní sekvence příkazů:		<p>Snad se už konečně vyřešil problém s upgradem databází obsahující extrémně velký počet LO (large objects). Nově binární upgrade (<code>pg_upgrade</code>) použije pro export metadat LO příkaz <code>COPY</code> místo původní sekvence příkazů:

PavelStehule: /* SQL/PGQ */

2026-09-15T11:09:43Z

SQL/PGQ

← Starší verze		Verze z 15. 9. 2026, 11:09
Řádek 316:		Řádek 316:
	<p>Osobně si nedovedu představit, že bych psal dotazy v SQL/PGQ (myslím, že podobně na tom bude většina uživatelů podobně). Je otázkou, jestli se SQL/PGQ neuplatní ve spolupráci s AI. V tomto případě se běžný dotaz rozpadá do dvou kroků. Navíc i joinovací podmínka získává label, takže je to v určitém smyslu více popisné, než běžné SQL, a je tak možné, že tento zápis bude AI více sedět.</p></s>		<p>Osobně si nedovedu představit, že bych psal dotazy v SQL/PGQ (myslím, že podobně na tom bude většina uživatelů podobně). Je otázkou, jestli se SQL/PGQ neuplatní ve spolupráci s AI. V tomto případě se běžný dotaz rozpadá do dvou kroků. Navíc i joinovací podmínka získává label, takže je to v určitém smyslu více popisné, než běžné SQL, a je tak možné, že tento zápis bude AI více sedět.</p></s>

	~~<s>~~<b>Odstraněno před vydáním</b><p>Pomalu se pokračuje na implementaci tzv temporálních tabulek. Letos je to podpora klauzule <code>FOR PORTION OF valid_at FROM TO</code>. Zjednodušeně, pokud máme temporální databáze nebo temporální tabulky, tak se můžeme podívat na stav dat v nějakém čase. Pokud se použije klauzule <code>FOR PORTION OF FROM TO</code>, tak se jedná o tzv temporální <code>UPDATE</code>, <code>DELETE</code~~></s~~>:		==Temporální tabulky==
			<b>Odstraněno před vydáním</b>
			<s><p>Pomalu se pokračuje na implementaci tzv temporálních tabulek. Letos je to podpora klauzule <code>FOR PORTION OF valid_at FROM TO</code>. Zjednodušeně, pokud máme temporální databáze nebo temporální tabulky, tak se můžeme podívat na stav dat v nějakém čase. Pokud se použije klauzule <code>FOR PORTION OF FROM TO</code>, tak se jedná o tzv temporální <code>UPDATE</code>, <code>DELETE</code>:
	<pre>		<pre>
	-- je nutne mit nainstalovanou extenzi btree_gist		-- je nutne mit nainstalovanou extenzi btree_gist
Řádek 357:		Řádek 359:
	(3 rows)		(3 rows)
	</pre>		</pre>
			</s>

	==Nové datové typy a funkce==		==Nové datové typy a funkce==

PavelStehule: /* SQL/PGQ */

2026-09-15T11:08:30Z

SQL/PGQ

← Starší verze		Verze z 15. 9. 2026, 11:08
Řádek 316:		Řádek 316:
	<p>Osobně si nedovedu představit, že bych psal dotazy v SQL/PGQ (myslím, že podobně na tom bude většina uživatelů podobně). Je otázkou, jestli se SQL/PGQ neuplatní ve spolupráci s AI. V tomto případě se běžný dotaz rozpadá do dvou kroků. Navíc i joinovací podmínka získává label, takže je to v určitém smyslu více popisné, než běžné SQL, a je tak možné, že tento zápis bude AI více sedět.</p></s>		<p>Osobně si nedovedu představit, že bych psal dotazy v SQL/PGQ (myslím, že podobně na tom bude většina uživatelů podobně). Je otázkou, jestli se SQL/PGQ neuplatní ve spolupráci s AI. V tomto případě se běžný dotaz rozpadá do dvou kroků. Navíc i joinovací podmínka získává label, takže je to v určitém smyslu více popisné, než běžné SQL, a je tak možné, že tento zápis bude AI více sedět.</p></s>

	<p>Pomalu se pokračuje na implementaci tzv temporálních tabulek. Letos je to podpora klauzule <code>FOR PORTION OF valid_at FROM TO</code>. Zjednodušeně, pokud máme temporální databáze nebo temporální tabulky, tak se můžeme podívat na stav dat v nějakém čase. Pokud se použije klauzule <code>FOR PORTION OF FROM TO</code>, tak se jedná o tzv temporální <code>UPDATE</code>, <code>DELETE</code>:		<s><b>Odstraněno před vydáním</b><p>Pomalu se pokračuje na implementaci tzv temporálních tabulek. Letos je to podpora klauzule <code>FOR PORTION OF valid_at FROM TO</code>. Zjednodušeně, pokud máme temporální databáze nebo temporální tabulky, tak se můžeme podívat na stav dat v nějakém čase. Pokud se použije klauzule <code>FOR PORTION OF FROM TO</code>, tak se jedná o tzv temporální <code>UPDATE</code>, <code>DELETE</code></s>:
	<pre>		<pre>
	-- je nutne mit nainstalovanou extenzi btree_gist		-- je nutne mit nainstalovanou extenzi btree_gist

PavelStehule: /* SQL/PGQ */

2026-09-08T04:42:34Z

SQL/PGQ

← Starší verze		Verze z 8. 9. 2026, 04:42
Řádek 250:		Řádek 250:

	==SQL/PGQ==		==SQL/PGQ==
	<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>		<b>Tato funkce byla z pg 19 odstraněna před vydáním</b>

			<s><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 312:		Řádek 314:
	</pre></p>		</pre></p>

	<p>Osobně si nedovedu představit, že bych psal dotazy v SQL/PGQ (myslím, že podobně na tom bude většina uživatelů podobně). Je otázkou, jestli se SQL/PGQ neuplatní ve spolupráci s AI. V tomto případě se běžný dotaz rozpadá do dvou kroků. Navíc i joinovací podmínka získává label, takže je to v určitém smyslu více popisné, než běžné SQL, a je tak možné, že tento zápis bude AI více sedět.</p>		<p>Osobně si nedovedu představit, že bych psal dotazy v SQL/PGQ (myslím, že podobně na tom bude většina uživatelů podobně). Je otázkou, jestli se SQL/PGQ neuplatní ve spolupráci s AI. V tomto případě se běžný dotaz rozpadá do dvou kroků. Navíc i joinovací podmínka získává label, takže je to v určitém smyslu více popisné, než běžné SQL, a je tak možné, že tento zápis bude AI více sedět.</p></s>

	<p>Pomalu se pokračuje na implementaci tzv temporálních tabulek. Letos je to podpora klauzule <code>FOR PORTION OF valid_at FROM TO</code>. Zjednodušeně, pokud máme temporální databáze nebo temporální tabulky, tak se můžeme podívat na stav dat v nějakém čase. Pokud se použije klauzule <code>FOR PORTION OF FROM TO</code>, tak se jedná o tzv temporální <code>UPDATE</code>, <code>DELETE</code>:		<p>Pomalu se pokračuje na implementaci tzv temporálních tabulek. Letos je to podpora klauzule <code>FOR PORTION OF valid_at FROM TO</code>. Zjednodušeně, pokud máme temporální databáze nebo temporální tabulky, tak se můžeme podívat na stav dat v nějakém čase. Pokud se použije klauzule <code>FOR PORTION OF FROM TO</code>, tak se jedná o tzv temporální <code>UPDATE</code>, <code>DELETE</code>:

PavelStehule v 27. 8. 2026, 04:21

2026-08-27T04:21:40Z

← Starší verze		Verze z 27. 8. 2026, 04:21
Řádek 112:		Řádek 112:
	<p>Poměrně razantně se změnila konfigurace <code>log_min_messages</code>, která udává, na které úrovni se mají chyby zapsat do systémového logu (<code>DEBUG5</code>..<code>PANIC</code>). Nově lze tuto úroveň nastavit pro každý typ procesu (<code>archiver</code>, <code>autovacuum</code>, <code>backend</code>, <code>bgworker</code>, ...) např. <code>error, walsender:debug1, autovacuum:debug1</code>.</p>		<p>Poměrně razantně se změnila konfigurace <code>log_min_messages</code>, která udává, na které úrovni se mají chyby zapsat do systémového logu (<code>DEBUG5</code>..<code>PANIC</code>). Nově lze tuto úroveň nastavit pro každý typ procesu (<code>archiver</code>, <code>autovacuum</code>, <code>backend</code>, <code>bgworker</code>, ...) např. <code>error, walsender:debug1, autovacuum:debug1</code>.</p>

	<p><s>Správa partišen (partitions) byla v Postgresu základní. Díky možnosti sloučit nebo rozdělit partišny (partitions) se dostává trochu dál. Je to spíš první krok se spoustou omezení - používá se pouze jedno CPU a po celou dobu je exkluzivně zamknutá rodičovská tabulka. Ale i tak to může dost uživatelům ušetřit práci (a jejich vlastní řešení by pravděpodobně mělo stejná omezení):		<p>odstraněno před vydáním<s>Správa partišen (partitions) byla v Postgresu základní. Díky možnosti sloučit nebo rozdělit partišny (partitions) se dostává trochu dál. Je to spíš první krok se spoustou omezení - používá se pouze jedno CPU a po celou dobu je exkluzivně zamknutá rodičovská tabulka. Ale i tak to může dost uživatelům ušetřit práci (a jejich vlastní řešení by pravděpodobně mělo stejná omezení):
	<pre>		<pre>
	ALTER TABLE sales_list MERGE PARTITIONS (sales_west, sales_east, sales_central) INTO sales_all;		ALTER TABLE sales_list MERGE PARTITIONS (sales_west, sales_east, sales_central) INTO sales_all;
Řádek 120:		Řádek 120:
	PARTITION measurement_y2006m02 FOR VALUES FROM ('2006-02-01') TO ('2006-03-01'),		PARTITION measurement_y2006m02 FOR VALUES FROM ('2006-02-01') TO ('2006-03-01'),
	PARTITION measurement_y2006m03 FOR VALUES FROM ('2006-03-01') TO ('2006-04-01'));		PARTITION measurement_y2006m03 FOR VALUES FROM ('2006-03-01') TO ('2006-04-01'));
	</pre></s>~~odstraněno před vydáním~~</p>		</pre></s></p>

	<p>Oproti předchozím verzím lze zapínat a vypínat všechny typy omezení (nejen cizí klíče):		<p>Oproti předchozím verzím lze zapínat a vypínat všechny typy omezení (nejen cizí klíče):

PavelStehule v 27. 8. 2026, 04:20

2026-08-27T04:20:57Z

← Starší verze		Verze z 27. 8. 2026, 04:20
Řádek 112:		Řádek 112:
	<p>Poměrně razantně se změnila konfigurace <code>log_min_messages</code>, která udává, na které úrovni se mají chyby zapsat do systémového logu (<code>DEBUG5</code>..<code>PANIC</code>). Nově lze tuto úroveň nastavit pro každý typ procesu (<code>archiver</code>, <code>autovacuum</code>, <code>backend</code>, <code>bgworker</code>, ...) např. <code>error, walsender:debug1, autovacuum:debug1</code>.</p>		<p>Poměrně razantně se změnila konfigurace <code>log_min_messages</code>, která udává, na které úrovni se mají chyby zapsat do systémového logu (<code>DEBUG5</code>..<code>PANIC</code>). Nově lze tuto úroveň nastavit pro každý typ procesu (<code>archiver</code>, <code>autovacuum</code>, <code>backend</code>, <code>bgworker</code>, ...) např. <code>error, walsender:debug1, autovacuum:debug1</code>.</p>

	<p>Správa partišen (partitions) byla v Postgresu základní. Díky možnosti sloučit nebo rozdělit partišny (partitions) se dostává trochu dál. Je to spíš první krok se spoustou omezení - používá se pouze jedno CPU a po celou dobu je exkluzivně zamknutá rodičovská tabulka. Ale i tak to může dost uživatelům ušetřit práci (a jejich vlastní řešení by pravděpodobně mělo stejná omezení):		<p><s>Správa partišen (partitions) byla v Postgresu základní. Díky možnosti sloučit nebo rozdělit partišny (partitions) se dostává trochu dál. Je to spíš první krok se spoustou omezení - používá se pouze jedno CPU a po celou dobu je exkluzivně zamknutá rodičovská tabulka. Ale i tak to může dost uživatelům ušetřit práci (a jejich vlastní řešení by pravděpodobně mělo stejná omezení):
	<pre>		<pre>
	ALTER TABLE sales_list MERGE PARTITIONS (sales_west, sales_east, sales_central) INTO sales_all;		ALTER TABLE sales_list MERGE PARTITIONS (sales_west, sales_east, sales_central) INTO sales_all;
Řádek 120:		Řádek 120:
	PARTITION measurement_y2006m02 FOR VALUES FROM ('2006-02-01') TO ('2006-03-01'),		PARTITION measurement_y2006m02 FOR VALUES FROM ('2006-02-01') TO ('2006-03-01'),
	PARTITION measurement_y2006m03 FOR VALUES FROM ('2006-03-01') TO ('2006-04-01'));		PARTITION measurement_y2006m03 FOR VALUES FROM ('2006-03-01') TO ('2006-04-01'));
	</pre></p>		</pre></s>odstraněno před vydáním</p>

	<p>Oproti předchozím verzím lze zapínat a vypínat všechny typy omezení (nejen cizí klíče):		<p>Oproti předchozím verzím lze zapínat a vypínat všechny typy omezení (nejen cizí klíče):

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>