feature freeze postgresu 19

[Pavel Stehule]

Ahoj

jestli se nepletu dnes by melo skoncit zaclenovani patchu do Postgresu 19.

Viditelnych novinek je v pg 19 opravdu hodne - poznamenal jsem si https://postgres.cz/wiki/Patche_19

Asi nejpopularnejsi ficurou asi bude REPACK (CONCURRENTLY) - coz je novy prikaz nahrazujici VACUUM FULL a CLUSTER, ktery nemusi exkluzivne zamykat (volba CONCURRENTLY vyzaduje existenci primarniho klice). Jsou tam jeste nejaka omezeni - nicmene, kdyz je nejaka nouzovka, tak se to muze hodit.

(2026-04-07 08:52:25) postgres=# repack (concurrently) foo;
REPACK
(2026-04-07 08:52:29) postgres=# repack (concurrently, verbose) foo;
INFO:  repacking "public.foo" in physical order
INFO:  "public.foo": found 0 removable, 100000 nonremovable row versions in 448 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU: user: 0.11 s, system: 0.00 s, elapsed: 0.11 s.
REPACK

[Tomas Vondra]

Až zítra ve 12:00 UTC:

https://www.postgresql.org/message-id/ab1YPhD9XNwQH7Kn%40nathan

On 4/7/26 08:59, Pavel Stehule wrote:
> Ahoj
>
> jestli se nepletu dnes by melo skoncit zaclenovani patchu do Postgresu 19.
>
> Viditelnych novinek je v pg 19 opravdu hodne - poznamenal jsem si

> https://postgres.cz/wiki/Patche_19 <https://postgres.cz/wiki/Patche_19>

>
> Asi nejpopularnejsi ficurou asi bude REPACK (CONCURRENTLY) - coz je novy
> prikaz nahrazujici VACUUM FULL a CLUSTER, ktery nemusi exkluzivne
> zamykat (volba CONCURRENTLY vyzaduje existenci primarniho klice). Jsou
> tam jeste nejaka omezeni - nicmene, kdyz je nejaka nouzovka, tak se to
> muze hodit.
>
> (2026-04-07 08:52:25) postgres=# repack (concurrently) foo;
> REPACK
> (2026-04-07 08:52:29) postgres=# repack (concurrently, verbose) foo;
> INFO:  repacking "public.foo" in physical order
> INFO:  "public.foo": found 0 removable, 100000 nonremovable row versions
> in 448 pages
> DETAIL:  0 dead row versions cannot be removed yet.
> CPU: user: 0.11 s, system: 0.00 s, elapsed: 0.11 s.
> REPACK
>
>
>
>
>

> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu postgresql-c...@googlegroups.com
> <mailto:postgresql-c...@googlegroups.com>.
> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/
> postgresql-cz/CAFj8pRB%3D%3DpOfyNNpH5HHwjaM-
> ksGz3aW8%3DHO1ZWXVNMuZGek0Q%40mail.gmail.com <https://groups.google.com/
> d/msgid/postgresql-cz/CAFj8pRB%3D%3DpOfyNNpH5HHwjaM-
> ksGz3aW8%3DHO1ZWXVNMuZGek0Q%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Pavel Stehule]

út 7. 4. 2026 v 11:46 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

Až zítra ve 12:00 UTC:

https://www.postgresql.org/message-id/ab1YPhD9XNwQH7Kn%40nathan

Diky za korekci

Pavel

[David Turoň]

Ahoj, 

to je urcite super novinka... ja jsem zrovna minuly tyden cetl clanek o repacku https://www.depesz.com/2026/03/19/waiting-for-postgresql-19-introduce-the-repack-command/
ale tam bylo, ze jeste nepodporuje concurently, ale je to z brezna... tak asi uz se to doimplementovalo.

Dik, za info

David

út 7. 4. 2026 v 9:00 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB%3D%3DpOfyNNpH5HHwjaM-ksGz3aW8%3DHO1ZWXVNMuZGek0Q%40mail.gmail.com.

[Josef Šimánek]

út 7. 4. 2026 v 13:54 odesílatel David Turoň <turon...@gmail.com> napsal:

>
> Ahoj,
> to je urcite super novinka... ja jsem zrovna minuly tyden cetl clanek o repacku https://www.depesz.com/2026/03/19/waiting-for-postgresql-19-introduce-the-repack-command/
> ale tam bylo, ze jeste nepodporuje concurently, ale je to z brezna... tak asi uz se to doimplementovalo.

Ještě se to furt ladí, to vlákno je "nekonečný" -
https://www.postgresql.org/message-id/flat/202507262156.sb455angijk6%40alvherre.pgsql.

A je tam i česká stopa!

> Dik, za info
>
> David
>
>
> út 7. 4. 2026 v 9:00 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:
>>
>> Ahoj
>>
>> jestli se nepletu dnes by melo skoncit zaclenovani patchu do Postgresu 19.
>>
>> Viditelnych novinek je v pg 19 opravdu hodne - poznamenal jsem si https://postgres.cz/wiki/Patche_19
>>
>> Asi nejpopularnejsi ficurou asi bude REPACK (CONCURRENTLY) - coz je novy prikaz nahrazujici VACUUM FULL a CLUSTER, ktery nemusi exkluzivne zamykat (volba CONCURRENTLY vyzaduje existenci primarniho klice). Jsou tam jeste nejaka omezeni - nicmene, kdyz je nejaka nouzovka, tak se to muze hodit.
>>
>> (2026-04-07 08:52:25) postgres=# repack (concurrently) foo;
>> REPACK
>> (2026-04-07 08:52:29) postgres=# repack (concurrently, verbose) foo;
>> INFO: repacking "public.foo" in physical order
>> INFO: "public.foo": found 0 removable, 100000 nonremovable row versions in 448 pages
>> DETAIL: 0 dead row versions cannot be removed yet.
>> CPU: user: 0.11 s, system: 0.00 s, elapsed: 0.11 s.
>> REPACK
>>
>>
>>
>>
>>
>> --
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
>> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB%3D%3DpOfyNNpH5HHwjaM-ksGz3aW8%3DHO1ZWXVNMuZGek0Q%40mail.gmail.com.
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFn00_xv4nvhhXteL%3DCdgTp5Kze%3DrrO5n%2BdTqOth54tqMuztSw%40mail.gmail.com.

[Pavel Stehule]

út 7. 4. 2026 v 13:54 odesílatel David Turoň <turon...@gmail.com> napsal:

Ahoj, 

to je urcite super novinka... ja jsem zrovna minuly tyden cetl clanek o repacku https://www.depesz.com/2026/03/19/waiting-for-postgresql-19-introduce-the-repack-command/
ale tam bylo, ze jeste nepodporuje concurently, ale je to z brezna... tak asi uz se to doimplementovalo.

mergovalo se to vcera 

Dik, za info

David

út 7. 4. 2026 v 9:00 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

Ahoj

jestli se nepletu dnes by melo skoncit zaclenovani patchu do Postgresu 19.

Viditelnych novinek je v pg 19 opravdu hodne - poznamenal jsem si https://postgres.cz/wiki/Patche_19

Asi nejpopularnejsi ficurou asi bude REPACK (CONCURRENTLY) - coz je novy prikaz nahrazujici VACUUM FULL a CLUSTER, ktery nemusi exkluzivne zamykat (volba CONCURRENTLY vyzaduje existenci primarniho klice). Jsou tam jeste nejaka omezeni - nicmene, kdyz je nejaka nouzovka, tak se to muze hodit.

(2026-04-07 08:52:25) postgres=# repack (concurrently) foo;
REPACK
(2026-04-07 08:52:29) postgres=# repack (concurrently, verbose) foo;
INFO:  repacking "public.foo" in physical order
INFO:  "public.foo": found 0 removable, 100000 nonremovable row versions in 448 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU: user: 0.11 s, system: 0.00 s, elapsed: 0.11 s.
REPACK

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB%3D%3DpOfyNNpH5HHwjaM-ksGz3aW8%3DHO1ZWXVNMuZGek0Q%40mail.gmail.com.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFn00_xv4nvhhXteL%3DCdgTp5Kze%3DrrO5n%2BdTqOth54tqMuztSw%40mail.gmail.com.

[Antonin Houska]

Pavel Stehule <pavel....@gmail.com> wrote:

> Asi nejpopularnejsi ficurou asi bude REPACK (CONCURRENTLY) - coz je novy prikaz nahrazujici VACUUM FULL a CLUSTER, ktery nemusi
> exkluzivne zamykat (volba CONCURRENTLY vyzaduje existenci primarniho klice). Jsou tam jeste nejaka omezeni - nicmene, kdyz je nejaka
> nouzovka, tak se to muze hodit.

Ahoj,

předně bych rád připomněl, kdo vlastně spustil integraci pg_squeeze do jádra
PG :-)

https://www.postgresql.org/message-id/flat/CAFj8pRDK89FtY_yyGw7-MW-z...@mail.gmail.com

Jinak za "nouzovku" bych to považoval jen v případě, kdy se jedná o VACUUM
FULL. V případě náhrady za příkaz CLUSTER si myslím, že to může být užitečné i
v méně urgentních situacích.

Omezení jsou v podstatě stejná jako u pg_squeeze, ale od PG 20 se snad budou
postupně odstraňovat. Oproti pg_squeeze to má zatím dvě výhody:

1. Při vytváření nové tabulky se do transakčního logu (WAL) nezapisuje
informace, která je potřeba pro jen logickou replikaci. U pg_squeeze, jakožto
externího kódu, tomuto nešlo zabránit. Takže když to zpracovávalo tabulku,
která se současně replikovala, musel proces ("walsender"), který měl replikaci
na starost, dekódovat z WAL i "tuny" dat, která mu k ničemu nebyla, a která
musel po nějaký čas držet v paměti, eventuálně na disku.

2. Dekódování datových změn provádí samostatný proces ("background worker"),
takže by to nemělo zpožďovat archivaci popř. mazání segmentů WAL.


Tonda H.

[David Turoň]

Ahoj,

ok tak teda dik Pavle za jiskru a Tondo za praci nad vyvojem a taky vsem dalsim co jsem nemumyslne vynechal. Ono je taky fajn, ze oproti pg_sqeeze pokud se nepletu - tam muselo byt wal_level logical, coz vyzaduje restart + instalace extenze. A hlavne ten restart muze byt problem. Budu se tesit az to zkusim za par trochu dele trvajicich okamziku na produkci:)

David

út 7. 4. 2026 v 15:13 odesílatel 'Antonin Houska' via PostgreSQL-cz <postgr...@googlegroups.com> napsal:

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/222606.1775567626%40localhost.

[Pavel Stehule]

út 7. 4. 2026 v 15:13 odesílatel 'Antonin Houska' via PostgreSQL-cz <postgr...@googlegroups.com> napsal:

Pavel Stehule <pavel....@gmail.com> wrote:

> Asi nejpopularnejsi ficurou asi bude REPACK (CONCURRENTLY) - coz je novy prikaz nahrazujici VACUUM FULL a CLUSTER, ktery nemusi
> exkluzivne zamykat (volba CONCURRENTLY vyzaduje existenci primarniho klice). Jsou tam jeste nejaka omezeni - nicmene, kdyz je nejaka
> nouzovka, tak se to muze hodit.

Ahoj,

předně bych rád připomněl, kdo vlastně spustil integraci pg_squeeze do jádra
PG :-)

https://www.postgresql.org/message-id/flat/CAFj8pRDK89FtY_yyGw7-MW-z...@mail.gmail.com

Mně občas napadá věcí :-)

Důležitý je, kdo udělal tu práci. Nevypadá to komplikovaně, je to v podstatě replikační klient, ale práce na tom bylo mraky, co jsem viděl. Ani jsem si nedovedl představit, co to je práce a času. Už jenom, jak dlouho se řešilo, že to nebude VACUUM FULL CONCURRENTLY, ale REPACK.

A hlavně je tam mraky hnusných detailů, který se musí bezchybně ošetřit, jinak to tiše zmrví data.  

Jinak za "nouzovku" bych to považoval jen v případě, kdy se jedná o VACUUM
FULL. V případě náhrady za příkaz CLUSTER si myslím, že to může být užitečné i
v méně urgentních situacích.

Za ty roky jsem se naučil nějak bez VACUUM FULL žít, až na pár případů - kdy byla nouze nejvyšší. CLUSTER jsem snad nepoužil nikdy. Určitě se může hodit, já jen nebyl u toho, kdyby se sešly SQL, a určitý poměr velikosti tabulek a paměti, aby to mělo smysl řešit. Aktuálně ceny pamětí rostou, tak je dost možný, že se k něčemu takovému dostanu.

 

Omezení jsou v podstatě stejná jako u pg_squeeze, ale od PG 20 se snad budou
postupně odstraňovat. Oproti pg_squeeze to má zatím dvě výhody:

1. Při vytváření nové tabulky se do transakčního logu (WAL) nezapisuje
informace, která je potřeba pro jen logickou replikaci. U pg_squeeze, jakožto
externího kódu, tomuto nešlo zabránit. Takže když to zpracovávalo tabulku,
která se současně replikovala, musel proces ("walsender"), který měl replikaci
na starost, dekódovat z WAL i "tuny" dat, která mu k ničemu nebyla, a která
musel po nějaký čas držet v paměti, eventuálně na disku.

2. Dekódování datových změn provádí samostatný proces ("background worker"),
takže by to nemělo zpožďovat archivaci popř. mazání segmentů WAL.

hlavně je to integrované. Z pg_repacku jsem měl vždycky trochu husí kůži, a nebo to prostě nebylo po ruce, když to bylo potřeba. 

Z mýho pohledu je to trochu jako záchranný padák, běžně ho nepoužiješ, ale ve chvíli, kdy jde do tuhého, jsi rád, že ho máš. Myslím si, že určitě to pár lidem ušetří starosti. A stopro se najdou tydlíti, kteří teď budou repackovat každý den, když to bude možné. 

Pavel

[Pavel Stehule]

út 7. 4. 2026 v 16:59 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

Bude pár let trvat než se to zaběhá, a zjistí se jak to správně používat. Dovedu si představit, že zatím co doteď jsem 2x v roce pouštěl REINDEX CONCURRENTLY, tak teď 2x pustím REPACK - a VACUUM FULL, které se pouštělo 1x do roka nebo po nějakých archivacích vůbec nebudu řešit. Což je super. Ale na to budu potřebovat jednak 19 v produkci a pak tak rok provozu.

[Antonin Houska]

David Turoň <turon...@gmail.com> wrote:

> ok tak teda dik Pavle za jiskru a Tondo za praci nad vyvojem a taky vsem dalsim co jsem nemumyslne vynechal. Ono je taky fajn, ze oproti
> pg_sqeeze pokud se nepletu - tam muselo byt wal_level logical, coz vyzaduje restart + instalace extenze. A hlavne ten restart muze byt
> problem. Budu se tesit az to zkusim za par trochu dele trvajicich okamziku na produkci:)

Tak zrovna tohle přepnutí do wal_level=logical si od PG 19 bude umět provést i
pg_squeeze, to je na REPACKu nezávislé:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=67c20979ce

Ale i tak bych doporučil přecházet postupně na REPACK. Při začleňování kódu do
PG jsme sice neobjevili žádnou chybu, která by mohla ohrozit data uživatelů,
ale přece jen na vývoj postgresu kouká mnohem víc lidí, a kvalita kódu je
přirozeně vyšší.

Tonda H.

[David Turoň]

CLUSTER jsem kdysi pouzil, ale bylo to na jeste 9.6 na nejake tabulce s chronologickymi daty. Snazil jsem se, aby nejdulezitejsi dotazy nacitaly co nejmene stranek - spolu s nizsim fill faktorem tabulky i castecne zabranit rozbiti serazeni pomoci HOT update. Problem ale nastal u maintenance. Server byl replikovan na neplnohodnotnou repliku se slabsim HW a prave blokujici operace CLUSTER vedla k tomu, ze na masteru zaclo dochazet misto diky enormnimu zapisu do wal, tehda jsem to dal nezkoumal a duvodem byla spis chyba v navrhu nez nekde v PG. Resenim bylo wal_level na minimal, udelat CLUSTER a pak obnovit replikaci. Cele to tak bylo vice komplikaci nez uzitku... ale s CONCURRENTLY urcite dava vetsi smysl jeho pouziti...

David

út 7. 4. 2026 v 19:49 odesílatel 'Antonin Houska' via PostgreSQL-cz <postgr...@googlegroups.com> napsal:

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/233967.1775584190%40localhost.

[Pavel Stehule]

st 8. 4. 2026 v 19:52 odesílatel David Turoň <turon...@gmail.com> napsal:

CLUSTER jsem kdysi pouzil, ale bylo to na jeste 9.6 na nejake tabulce s chronologickymi daty. Snazil jsem se, aby nejdulezitejsi dotazy nacitaly co nejmene stranek - spolu s nizsim fill faktorem tabulky i castecne zabranit rozbiti serazeni pomoci HOT update. Problem ale nastal u maintenance. Server byl replikovan na neplnohodnotnou repliku se slabsim HW a prave blokujici operace CLUSTER vedla k tomu, ze na masteru zaclo dochazet misto diky enormnimu zapisu do wal, tehda jsem to dal nezkoumal a duvodem byla spis chyba v navrhu nez nekde v PG. Resenim bylo wal_level na minimal, udelat CLUSTER a pak obnovit replikaci. Cele to tak bylo vice komplikaci nez uzitku... ale s CONCURRENTLY urcite dava vetsi smysl jeho pouziti...

Osobne nemam pro CLUSTER zadny use case. Kdyz uz bych potreboval clustrovanou tabulku, tak bych spis pouzil MySQL INNODB. A kdybych to chtel moc v Postgresu, tak budto skrz FDW nebo bych to mozna nejak zabalil jako storage. 

Tady si myslim, ze je urcity progres https://github.com/skuznetsov/pg_sorted_heap nebo https://github.com/relytcloud/pg_ducklake.

pg_ducklake muze byt sikovna vec, ale zatim to neni ve stavu, kdy by se to dalo nasadit.

 

David

út 7. 4. 2026 v 19:49 odesílatel 'Antonin Houska' via PostgreSQL-cz <postgr...@googlegroups.com> napsal:

David Turoň <turon...@gmail.com> wrote:

> ok tak teda dik Pavle za jiskru a Tondo za praci nad vyvojem a taky vsem dalsim co jsem nemumyslne vynechal. Ono je taky fajn, ze oproti
> pg_sqeeze pokud se nepletu - tam muselo byt wal_level logical, coz vyzaduje restart + instalace extenze. A hlavne ten restart muze byt
> problem. Budu se tesit az to zkusim za par trochu dele trvajicich okamziku na produkci:)

Tak zrovna tohle přepnutí do wal_level=logical si od PG 19 bude umět provést i
pg_squeeze, to je na REPACKu nezávislé:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=67c20979ce

Ale i tak bych doporučil přecházet postupně na REPACK. Při začleňování kódu do
PG jsme sice neobjevili žádnou chybu, která by mohla ohrozit data uživatelů,
ale přece jen na vývoj postgresu kouká mnohem víc lidí, a kvalita kódu je
přirozeně vyšší.

Tonda H.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/233967.1775584190%40localhost.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFn00_wpwFt7_YmxR9Tsw5kxyziVwy_KR7Ew8Q-VU2FO58gB1A%40mail.gmail.com.

[Josef Šimánek]

st 8. 4. 2026 v 20:11 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

>
>
>
> st 8. 4. 2026 v 19:52 odesílatel David Turoň <turon...@gmail.com> napsal:
>>
>> CLUSTER jsem kdysi pouzil, ale bylo to na jeste 9.6 na nejake tabulce s chronologickymi daty. Snazil jsem se, aby nejdulezitejsi dotazy nacitaly co nejmene stranek - spolu s nizsim fill faktorem tabulky i castecne zabranit rozbiti serazeni pomoci HOT update. Problem ale nastal u maintenance. Server byl replikovan na neplnohodnotnou repliku se slabsim HW a prave blokujici operace CLUSTER vedla k tomu, ze na masteru zaclo dochazet misto diky enormnimu zapisu do wal, tehda jsem to dal nezkoumal a duvodem byla spis chyba v navrhu nez nekde v PG. Resenim bylo wal_level na minimal, udelat CLUSTER a pak obnovit replikaci. Cele to tak bylo vice komplikaci nez uzitku... ale s CONCURRENTLY urcite dava vetsi smysl jeho pouziti...
>
>
> Osobne nemam pro CLUSTER zadny use case. Kdyz uz bych potreboval clustrovanou tabulku, tak bych spis pouzil MySQL INNODB. A kdybych to chtel moc v Postgresu, tak budto skrz FDW nebo bych to mozna nejak zabalil jako storage.
>
> Tady si myslim, ze je urcity progres https://github.com/skuznetsov/pg_sorted_heap nebo https://github.com/relytcloud/pg_ducklake.
>
> pg_ducklake muze byt sikovna vec, ale zatim to neni ve stavu, kdy by se to dalo nasadit.

Já ducklake momentálně testuju (bez toho pg_ducklake, to vypadá jen
jako cukřík pro to USING) a vypadá to dobře. Proč by to nemělo být ve
stavu, kdy by se to dalo nasadit?

https://ducklake.select/faq#is-ducklake-production-ready

Tady sice uvádí, že 0.x není produkční. Ale podle plánu to vypadá že
je vše hotovo a brzo bude 1.0. https://ducklake.select/roadmap

> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRDWHdm-jqHe7D41PnVUTvfWq4h%3DStH42ZOE1gqQnp95bg%40mail.gmail.com.

[Pavel Stehule]

st 8. 4. 2026 v 20:23 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

st 8. 4. 2026 v 20:11 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:
>
>
>
> st 8. 4. 2026 v 19:52 odesílatel David Turoň <turon...@gmail.com> napsal:
>>
>> CLUSTER jsem kdysi pouzil, ale bylo to na jeste 9.6 na nejake tabulce s chronologickymi daty. Snazil jsem se, aby nejdulezitejsi dotazy nacitaly co nejmene stranek - spolu s nizsim fill faktorem tabulky i castecne zabranit rozbiti serazeni pomoci HOT update. Problem ale nastal u maintenance. Server byl replikovan na neplnohodnotnou repliku se slabsim HW a prave blokujici operace CLUSTER vedla k tomu, ze na masteru zaclo dochazet misto diky enormnimu zapisu do wal, tehda jsem to dal nezkoumal a duvodem byla spis chyba v navrhu nez nekde v PG. Resenim bylo wal_level na minimal, udelat CLUSTER a pak obnovit replikaci. Cele to tak bylo vice komplikaci nez uzitku... ale s CONCURRENTLY urcite dava vetsi smysl jeho pouziti...
>
>
> Osobne nemam pro CLUSTER zadny use case. Kdyz uz bych potreboval clustrovanou tabulku, tak bych spis pouzil MySQL INNODB. A kdybych to chtel moc v Postgresu, tak budto skrz FDW nebo bych to mozna nejak zabalil jako storage.
>
> Tady si myslim, ze je urcity progres https://github.com/skuznetsov/pg_sorted_heap nebo https://github.com/relytcloud/pg_ducklake.
>
> pg_ducklake muze byt sikovna vec, ale zatim to neni ve stavu, kdy by se to dalo nasadit.

Já ducklake momentálně testuju (bez toho pg_ducklake, to vypadá jen
jako cukřík pro to USING) a vypadá to dobře. Proč by to nemělo být ve
stavu, kdy by se to dalo nasadit?

https://ducklake.select/faq#is-ducklake-production-ready

Tady sice uvádí, že 0.x není produkční. Ale podle plánu to vypadá že
je vše hotovo a brzo bude 1.0. https://ducklake.select/roadmap

tak jsem postgresista, tak chci ten cukrik, a ten vuci 18tce nefunguje

https://github.com/relytcloud/pg_ducklake/issues/157

hral jsem si s tim chvilku, ze zvedavosti. Ale az to bude, tak to bude super. 

Trochu mi to pripomina stav Vertiky kdyz jsme si s ni hrali v GoodData kolem roku 2012. Bylo videt, ze to je bomba - byl to software, ktery se psal od roku 2004, ale navazovalo to na starsi projekty. Kdyz na to sahl kolem toho roku 2012 nepouceny clovek, tak behem par minut narazil na neco, co nefungovalo, a furt tam byly nejaky potize. DuckDB uz bude odladena. Tam je videt, ze to pouziva dneska desetitisice uzivatelu. Ale ty integrace s Postgresem jsou porad na zacatku. 

 

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFp7QwqRSbVr6c4C87u9TuBhzVdZsD_of19XTddmfgxKwJhdKg%40mail.gmail.com.