PostgreSQL 17 (2024) - Historie editací

PavelStehule v 22. 7. 2025, 16:17

2025-07-22T16:17:15Z

← Starší verze		Verze z 22. 7. 2025, 16:17
Řádek 705:		Řádek 705:
	<DPL>category=Verze PostgreSQL</DPL>		<DPL>category=Verze PostgreSQL</DPL>
	[[Category:Články]]		[[Category:Články]]
			[[Category:Verze PostgreSQL]]

PavelStehule v 22. 7. 2025, 16:17

2025-07-22T16:17:06Z

← Starší verze		Verze z 22. 7. 2025, 16:17
Řádek 705:		Řádek 705:
	<DPL>category=Verze PostgreSQL</DPL>		<DPL>category=Verze PostgreSQL</DPL>
	[[Category:Články]]		[[Category:Články]]
	~~[[Category:Verze PostgreSQL]]~~

PavelStehule: /* Pelmel */

2025-02-23T06:13:52Z

Pelmel

← Starší verze		Verze z 23. 2. 2025, 06:13
Řádek 571:		Řádek 571:
	===login trigger===		===login trigger===

	Novinkou v uložených procedurách je možnost vytvářet <code>login</code> triggery. Některé konkurenční databáze tuto funkcionalitu měly desetiletí, a pokud se z těchto databází migrovalo do Postgresu, tak to byl trochu problém (mimo cloud relativně jednoduše řešitelný extenzí např. ~~<a href="~~https://github.com/okbob/session_exec"><code>session_exec</code>~~</a>~~). S vestavěnou podporou extenze nejsou potřeba. Pozor, i integrované řešení má režii, a zpomalí connect. Ale s tím se musí počítat. V rámci login triggeru (patří do kategorie event triggerů) můžete dynamicky nastavit práva, vytvořit dočasné tabulky pro session, nastavit GUC proměnné:		Novinkou v uložených procedurách je možnost vytvářet <code>login</code> triggery. Některé konkurenční databáze tuto funkcionalitu měly desetiletí, a pokud se z těchto databází migrovalo do Postgresu, tak to byl trochu problém (mimo cloud relativně jednoduše řešitelný extenzí např. [https://github.com/okbob/session_exec <code>session_exec</code>]). S vestavěnou podporou extenze nejsou potřeba. Pozor, i integrované řešení má režii, a zpomalí connect. Ale s tím se musí počítat. V rámci login triggeru (patří do kategorie event triggerů) můžete dynamicky nastavit práva, vytvořit dočasné tabulky pro session, nastavit GUC proměnné:
	<pre>		<pre>
	CREATE OR REPLACE FUNCTION public.init_session()		CREATE OR REPLACE FUNCTION public.init_session()

PavelStehule: /* Partitioning */

2024-08-24T18:21:14Z

Partitioning

← Starší verze		Verze z 24. 8. 2024, 18:21
Řádek 511:		Řádek 511:
	===Partitioning===		===Partitioning===

	V PostgreSQL 17 můžeme partišny rozdělit příkazem <code>ALTER TABLE SPLIT PARTITION</code> nebo sloučit příkazem <code>ALTER TABLE MERGE PARTITIONS</code>. Příkazy vyžadují exkluzivní zámek <code>ACCESS EXCLUSIVE</code> nad partitiovanou tabulkou, tudíž pro vykonání těchto příkazů je nutná servisní odstávka aplikace. Dá se předpokládat, že v ne úplně vzdálené budoucnosti, dojde k podpoře paralelismu a k snížení úrovně zamykání.		V PostgreSQL 17 můžeme partišny rozdělit příkazem <code>ALTER TABLE SPLIT PARTITION</code> nebo sloučit příkazem <code>ALTER TABLE MERGE PARTITIONS</code>. Příkazy vyžadují exkluzivní zámek <code>ACCESS EXCLUSIVE</code> nad partitiovanou tabulkou, tudíž pro vykonání těchto příkazů je nutná servisní odstávka aplikace. Dá se předpokládat, že v ne úplně vzdálené budoucnosti, dojde k podpoře paralelismu a k snížení úrovně zamykání (poznámka - patch implementující tuto funkcionalitu byl revertnut před vydáním - důvodem je problém s bezpečností).

	<pre>		<pre>

PavelStehule v 11. 7. 2024, 07:26

2024-07-11T07:26:34Z

← Starší verze		Verze z 11. 7. 2024, 07:26
Řádek 1:		Řádek 1:
	<i>Autor: Pavel Stěhule, ~~2023~~</i>		<i>Autor: Pavel Stěhule, 2024</i>

	=PostgreSQL 17 (2024)=		=PostgreSQL 17 (2024)=

PavelStehule v 21. 5. 2024, 18:13

2024-05-21T18:13:16Z

← Starší verze		Verze z 21. 5. 2024, 18:13
Řádek 9:		Řádek 9:
	Tento vývojový cyklus byl bez jakýchkoliv kontroverzí. Je vidět snaha o dotáhnutí velkých patchů (jako např. SQL/JSON), a zároveň si nepodrazit zbytečně nohy rychlou integrací nového kódu. Neotevírají se nová velké témata (v rámci komunitního Postgresu). Výjimkou byl návrh Heikkiho Linnakangase na přechod z architektury postavené na procesech na architekturu používající vlákna. To je dost kontroverzní téma, které mělo přijít na přetřes před 10 roky. Architekturu Postgres přebírá ještě z databáze [https://en.wikipedia.org/wiki/Ingres_(database) INGRES</i>], což znamená, že je pomalu 50 let stará. V Postgresu je proces spojen s konkrétní databází a s konkrétním přihlášeným uživatelem. Bez ukončení procesu (a vytvoření nového) nejde změnit uživatele, nejde změnit databázi. Když máte intenzivně využívané aplikace se vyššími stovkami uživatelů, připojujících se do vyšších stovek databází, tak s Postgresem můžete mít problém. Řešení by mohla přinést změna architektury (využívání vláken). Před implementací podpory využití více CPU pro jeden dotaz by ale tento přechod byl o dost jednodušší, a také by se asi dost ušetřilo práce při implementaci komunikace mezi procesy workerů dotazu. Myslím si, že Postgres na vlákna přejde, ale bude to trvat roky. Problém není vlastní implementace (existují dva prototypy). Problém je, jak tuto velkou změnu rozložit v čase, a zároveň každý rok vydat verzi v očekávané kvalitě (a zároveň aby byl Postgres funkční a stabilní na všech systémech, které jsou podporovány).		Tento vývojový cyklus byl bez jakýchkoliv kontroverzí. Je vidět snaha o dotáhnutí velkých patchů (jako např. SQL/JSON), a zároveň si nepodrazit zbytečně nohy rychlou integrací nového kódu. Neotevírají se nová velké témata (v rámci komunitního Postgresu). Výjimkou byl návrh Heikkiho Linnakangase na přechod z architektury postavené na procesech na architekturu používající vlákna. To je dost kontroverzní téma, které mělo přijít na přetřes před 10 roky. Architekturu Postgres přebírá ještě z databáze [https://en.wikipedia.org/wiki/Ingres_(database) INGRES</i>], což znamená, že je pomalu 50 let stará. V Postgresu je proces spojen s konkrétní databází a s konkrétním přihlášeným uživatelem. Bez ukončení procesu (a vytvoření nového) nejde změnit uživatele, nejde změnit databázi. Když máte intenzivně využívané aplikace se vyššími stovkami uživatelů, připojujících se do vyšších stovek databází, tak s Postgresem můžete mít problém. Řešení by mohla přinést změna architektury (využívání vláken). Před implementací podpory využití více CPU pro jeden dotaz by ale tento přechod byl o dost jednodušší, a také by se asi dost ušetřilo práce při implementaci komunikace mezi procesy workerů dotazu. Myslím si, že Postgres na vlákna přejde, ale bude to trvat roky. Problém není vlastní implementace (existují dva prototypy). Problém je, jak tuto velkou změnu rozložit v čase, a zároveň každý rok vydat verzi v očekávané kvalitě (a zároveň aby byl Postgres funkční a stabilní na všech systémech, které jsou podporovány).

	~~Hikkiho~~ iniciativa pravděpodobně souvisí s projektem [https://neon.tech/docs/introduction/about <i>Neon</i>], v jehož týmu pracuje, a který spolu založil. Jde o open source velmi zajímavou alternativu Amazoního Aurora Postgresu. Jedná se o fork PostgreSQL upravený pro běh v cloudu. Oproti běžnému Postgresu, kde server řeší jak manipulaci s daty a správu cache (storage), tak vykonávaní dotazů (compute), jsou v Neonu storage a compute striktně odděleny, a běží v nezávislých VM. Management compute nody pak může být výrazně dynamičtější než s klasickým Postgresem (protože tam není ta část, která se stará o storage). Pro storage se používá speciální cloud multi-tenant storage systém, který podporuje i zálohování a archivaci.		Heikkiho iniciativa pravděpodobně souvisí s projektem [https://neon.tech/docs/introduction/about <i>Neon</i>], v jehož týmu pracuje, a který spolu založil. Jde o open source velmi zajímavou alternativu Amazoního Aurora Postgresu. Jedná se o fork PostgreSQL upravený pro běh v cloudu. Oproti běžnému Postgresu, kde server řeší jak manipulaci s daty a správu cache (storage), tak vykonávaní dotazů (compute), jsou v Neonu storage a compute striktně odděleny, a běží v nezávislých VM. Management compute nody pak může být výrazně dynamičtější než s klasickým Postgresem (protože tam není ta část, která se stará o storage). Pro storage se používá speciální cloud multi-tenant storage systém, který podporuje i zálohování a archivaci.

	==Datové typy==		==Datové typy==

PavelStehule v 21. 5. 2024, 18:12

2024-05-21T18:12:55Z

← Starší verze		Verze z 21. 5. 2024, 18:12
Řádek 9:		Řádek 9:
	Tento vývojový cyklus byl bez jakýchkoliv kontroverzí. Je vidět snaha o dotáhnutí velkých patchů (jako např. SQL/JSON), a zároveň si nepodrazit zbytečně nohy rychlou integrací nového kódu. Neotevírají se nová velké témata (v rámci komunitního Postgresu). Výjimkou byl návrh Heikkiho Linnakangase na přechod z architektury postavené na procesech na architekturu používající vlákna. To je dost kontroverzní téma, které mělo přijít na přetřes před 10 roky. Architekturu Postgres přebírá ještě z databáze [https://en.wikipedia.org/wiki/Ingres_(database) INGRES</i>], což znamená, že je pomalu 50 let stará. V Postgresu je proces spojen s konkrétní databází a s konkrétním přihlášeným uživatelem. Bez ukončení procesu (a vytvoření nového) nejde změnit uživatele, nejde změnit databázi. Když máte intenzivně využívané aplikace se vyššími stovkami uživatelů, připojujících se do vyšších stovek databází, tak s Postgresem můžete mít problém. Řešení by mohla přinést změna architektury (využívání vláken). Před implementací podpory využití více CPU pro jeden dotaz by ale tento přechod byl o dost jednodušší, a také by se asi dost ušetřilo práce při implementaci komunikace mezi procesy workerů dotazu. Myslím si, že Postgres na vlákna přejde, ale bude to trvat roky. Problém není vlastní implementace (existují dva prototypy). Problém je, jak tuto velkou změnu rozložit v čase, a zároveň každý rok vydat verzi v očekávané kvalitě (a zároveň aby byl Postgres funkční a stabilní na všech systémech, které jsou podporovány).		Tento vývojový cyklus byl bez jakýchkoliv kontroverzí. Je vidět snaha o dotáhnutí velkých patchů (jako např. SQL/JSON), a zároveň si nepodrazit zbytečně nohy rychlou integrací nového kódu. Neotevírají se nová velké témata (v rámci komunitního Postgresu). Výjimkou byl návrh Heikkiho Linnakangase na přechod z architektury postavené na procesech na architekturu používající vlákna. To je dost kontroverzní téma, které mělo přijít na přetřes před 10 roky. Architekturu Postgres přebírá ještě z databáze [https://en.wikipedia.org/wiki/Ingres_(database) INGRES</i>], což znamená, že je pomalu 50 let stará. V Postgresu je proces spojen s konkrétní databází a s konkrétním přihlášeným uživatelem. Bez ukončení procesu (a vytvoření nového) nejde změnit uživatele, nejde změnit databázi. Když máte intenzivně využívané aplikace se vyššími stovkami uživatelů, připojujících se do vyšších stovek databází, tak s Postgresem můžete mít problém. Řešení by mohla přinést změna architektury (využívání vláken). Před implementací podpory využití více CPU pro jeden dotaz by ale tento přechod byl o dost jednodušší, a také by se asi dost ušetřilo práce při implementaci komunikace mezi procesy workerů dotazu. Myslím si, že Postgres na vlákna přejde, ale bude to trvat roky. Problém není vlastní implementace (existují dva prototypy). Problém je, jak tuto velkou změnu rozložit v čase, a zároveň každý rok vydat verzi v očekávané kvalitě (a zároveň aby byl Postgres funkční a stabilní na všech systémech, které jsou podporovány).

	~~Heikkiho~~ iniciativa pravděpodobně souvisí s projektem [https://neon.tech/docs/introduction/about <i>Neon</i>], v jehož týmu pracuje, a který spolu založil. Jde o open source velmi zajímavou alternativu Amazoního Aurora Postgresu. Jedná se o fork PostgreSQL upravený pro běh v cloudu. Oproti běžnému Postgresu, kde server řeší jak manipulaci s daty a správu cache (storage), tak vykonávaní dotazů (compute), jsou v Neonu storage a compute striktně odděleny, a běží v nezávislých VM. Management compute nody pak může být výrazně dynamičtější než s klasickým Postgresem (protože tam není ta část, která se stará o storage). Pro storage se používá speciální cloud multi-tenant storage systém, který podporuje i zálohování a archivaci.		Hikkiho iniciativa pravděpodobně souvisí s projektem [https://neon.tech/docs/introduction/about <i>Neon</i>], v jehož týmu pracuje, a který spolu založil. Jde o open source velmi zajímavou alternativu Amazoního Aurora Postgresu. Jedná se o fork PostgreSQL upravený pro běh v cloudu. Oproti běžnému Postgresu, kde server řeší jak manipulaci s daty a správu cache (storage), tak vykonávaní dotazů (compute), jsou v Neonu storage a compute striktně odděleny, a běží v nezávislých VM. Management compute nody pak může být výrazně dynamičtější než s klasickým Postgresem (protože tam není ta část, která se stará o storage). Pro storage se používá speciální cloud multi-tenant storage systém, který podporuje i zálohování a archivaci.

	==Datové typy==		==Datové typy==
Řádek 363:		Řádek 363:
	===Optimalizace dotazů===		===Optimalizace dotazů===

	Planner nyní vidí statistiky zanořené CTE. Inkrementální řazení (implementováno v PostgreSQL 13) je možné použít i vůči GiST a SP-GiST indexům. To může být užitečné pro KNN dotazy, kde se řadí i podle neoindexovaného sloupce. V případě více sloupcové klauzule <code>GROUP BY</code> optimalizátor vyzkouší více kombinací řazení, tak aby minimalizoval jeho náročnost (aby bylo možné použít inkrementální řazení).		Implementace <code>UNION</code>u bude o něco chytřejší - kromě operace <code>append</code> bude možné použít i operaci <code>merge append</code> (pokud jsou vstupní data již seřazená, tak není nutný další sort a unique). Planner nyní vidí statistiky zanořené CTE. Inkrementální řazení (implementováno v PostgreSQL 13) je možné použít i vůči GiST a SP-GiST indexům. To může být užitečné pro KNN dotazy, kde se řadí i podle neoindexovaného sloupce. V případě více sloupcové klauzule <code>GROUP BY</code> optimalizátor vyzkouší více kombinací řazení, tak aby minimalizoval jeho náročnost (aby bylo možné použít inkrementální řazení).

	Postgres nyní podporuje tzv <i>index skip scan</i>. To znamená, že pokud v indexu vyhledáváte seznam hodnot, tak oproti dřívější implementaci, která n krát vyhledávala konkrétní hodnotu, a n krát opakovala traverzování napříč indexem. Nově se dohledaných listech (koncové uzly indexu) zkouší dohledat další hodnoty ze seznamu.		Postgres nyní podporuje tzv <i>index skip scan</i>. To znamená, že pokud v indexu vyhledáváte seznam hodnot, tak oproti dřívější implementaci, která n krát vyhledávala konkrétní hodnotu, a n krát opakovala traverzování napříč indexem. Nově se dohledaných listech (koncové uzly indexu) zkouší dohledat další hodnoty ze seznamu.

PavelStehule: /* PostgreSQL 17 (2024) */

2024-05-20T19:25:29Z

PostgreSQL 17 (2024)

← Starší verze		Verze z 20. 5. 2024, 19:25
Řádek 9:		Řádek 9:
	Tento vývojový cyklus byl bez jakýchkoliv kontroverzí. Je vidět snaha o dotáhnutí velkých patchů (jako např. SQL/JSON), a zároveň si nepodrazit zbytečně nohy rychlou integrací nového kódu. Neotevírají se nová velké témata (v rámci komunitního Postgresu). Výjimkou byl návrh Heikkiho Linnakangase na přechod z architektury postavené na procesech na architekturu používající vlákna. To je dost kontroverzní téma, které mělo přijít na přetřes před 10 roky. Architekturu Postgres přebírá ještě z databáze [https://en.wikipedia.org/wiki/Ingres_(database) INGRES</i>], což znamená, že je pomalu 50 let stará. V Postgresu je proces spojen s konkrétní databází a s konkrétním přihlášeným uživatelem. Bez ukončení procesu (a vytvoření nového) nejde změnit uživatele, nejde změnit databázi. Když máte intenzivně využívané aplikace se vyššími stovkami uživatelů, připojujících se do vyšších stovek databází, tak s Postgresem můžete mít problém. Řešení by mohla přinést změna architektury (využívání vláken). Před implementací podpory využití více CPU pro jeden dotaz by ale tento přechod byl o dost jednodušší, a také by se asi dost ušetřilo práce při implementaci komunikace mezi procesy workerů dotazu. Myslím si, že Postgres na vlákna přejde, ale bude to trvat roky. Problém není vlastní implementace (existují dva prototypy). Problém je, jak tuto velkou změnu rozložit v čase, a zároveň každý rok vydat verzi v očekávané kvalitě (a zároveň aby byl Postgres funkční a stabilní na všech systémech, které jsou podporovány).		Tento vývojový cyklus byl bez jakýchkoliv kontroverzí. Je vidět snaha o dotáhnutí velkých patchů (jako např. SQL/JSON), a zároveň si nepodrazit zbytečně nohy rychlou integrací nového kódu. Neotevírají se nová velké témata (v rámci komunitního Postgresu). Výjimkou byl návrh Heikkiho Linnakangase na přechod z architektury postavené na procesech na architekturu používající vlákna. To je dost kontroverzní téma, které mělo přijít na přetřes před 10 roky. Architekturu Postgres přebírá ještě z databáze [https://en.wikipedia.org/wiki/Ingres_(database) INGRES</i>], což znamená, že je pomalu 50 let stará. V Postgresu je proces spojen s konkrétní databází a s konkrétním přihlášeným uživatelem. Bez ukončení procesu (a vytvoření nového) nejde změnit uživatele, nejde změnit databázi. Když máte intenzivně využívané aplikace se vyššími stovkami uživatelů, připojujících se do vyšších stovek databází, tak s Postgresem můžete mít problém. Řešení by mohla přinést změna architektury (využívání vláken). Před implementací podpory využití více CPU pro jeden dotaz by ale tento přechod byl o dost jednodušší, a také by se asi dost ušetřilo práce při implementaci komunikace mezi procesy workerů dotazu. Myslím si, že Postgres na vlákna přejde, ale bude to trvat roky. Problém není vlastní implementace (existují dva prototypy). Problém je, jak tuto velkou změnu rozložit v čase, a zároveň každý rok vydat verzi v očekávané kvalitě (a zároveň aby byl Postgres funkční a stabilní na všech systémech, které jsou podporovány).

	~~Hikkiho~~ iniciativa pravděpodobně souvisí s projektem [https://neon.tech/docs/introduction/about <i>Neon</i>], v jehož týmu pracuje, a který spolu založil. Jde o open source velmi zajímavou alternativu Amazoního Aurora Postgresu. Jedná se o fork PostgreSQL upravený pro běh v cloudu. Oproti běžnému Postgresu, kde server řeší jak manipulaci s daty a správu cache (storage), tak vykonávaní dotazů (compute), jsou v Neonu storage a compute striktně odděleny, a běží v nezávislých VM. Management compute nody pak může být výrazně dynamičtější než s klasickým Postgresem (protože tam není ta část, která se stará o storage). Pro storage se používá speciální cloud multi-tenant storage systém, který podporuje i zálohování a archivaci.		Heikkiho iniciativa pravděpodobně souvisí s projektem [https://neon.tech/docs/introduction/about <i>Neon</i>], v jehož týmu pracuje, a který spolu založil. Jde o open source velmi zajímavou alternativu Amazoního Aurora Postgresu. Jedná se o fork PostgreSQL upravený pro běh v cloudu. Oproti běžnému Postgresu, kde server řeší jak manipulaci s daty a správu cache (storage), tak vykonávaní dotazů (compute), jsou v Neonu storage a compute striktně odděleny, a běží v nezávislých VM. Management compute nody pak může být výrazně dynamičtější než s klasickým Postgresem (protože tam není ta část, která se stará o storage). Pro storage se používá speciální cloud multi-tenant storage systém, který podporuje i zálohování a archivaci.

	==Datové typy==		==Datové typy==

PavelStehule: /* Optimalizace dotazů */

2024-05-20T19:23:37Z

Optimalizace dotazů

← Starší verze		Verze z 20. 5. 2024, 19:23
Řádek 363:		Řádek 363:
	===Optimalizace dotazů===		===Optimalizace dotazů===

	Implementace <code>UNION</code>u bude o něco chytřejší - kromě operace <code>append</code> bude možné použít i operaci <code>merge append</code> (pokud jsou vstupní data již seřazená, tak není nutný další sort a unique). Planner nyní vidí statistiky zanořené CTE. Inkrementální řazení (implementováno v PostgreSQL 13) je možné použít i vůči GiST a SP-GiST indexům. To může být užitečné pro KNN dotazy, kde se řadí i podle neoindexovaného sloupce. V případě více sloupcové klauzule <code>GROUP BY</code> optimalizátor vyzkouší více kombinací řazení, tak aby minimalizoval jeho náročnost (aby bylo možné použít inkrementální řazení).		Planner nyní vidí statistiky zanořené CTE. Inkrementální řazení (implementováno v PostgreSQL 13) je možné použít i vůči GiST a SP-GiST indexům. To může být užitečné pro KNN dotazy, kde se řadí i podle neoindexovaného sloupce. V případě více sloupcové klauzule <code>GROUP BY</code> optimalizátor vyzkouší více kombinací řazení, tak aby minimalizoval jeho náročnost (aby bylo možné použít inkrementální řazení).

	Postgres nyní podporuje tzv <i>index skip scan</i>. To znamená, že pokud v indexu vyhledáváte seznam hodnot, tak oproti dřívější implementaci, která n krát vyhledávala konkrétní hodnotu, a n krát opakovala traverzování napříč indexem. Nově se dohledaných listech (koncové uzly indexu) zkouší dohledat další hodnoty ze seznamu.		Postgres nyní podporuje tzv <i>index skip scan</i>. To znamená, že pokud v indexu vyhledáváte seznam hodnot, tak oproti dřívější implementaci, která n krát vyhledávala konkrétní hodnotu, a n krát opakovala traverzování napříč indexem. Nově se dohledaných listech (koncové uzly indexu) zkouší dohledat další hodnoty ze seznamu.

PavelStehule: založena nová stránka s textem „Autor: Pavel Stěhule, 2023 =PostgreSQL 17 (2024)= Už jsem to psal posledně, tím jak na Postgresu dělá víc a víc vývojářů z různých s…“

2024-05-17T04:43:07Z

založena nová stránka s textem „<i>Autor: Pavel Stěhule, 2023</i> =PostgreSQL 17 (2024)= Už jsem to psal posledně, tím jak na Postgresu dělá víc a víc vývojářů z různých s…“

Ukázat změny