TAM - potencialni nahrada za autonomni transakce

10 views
Skip to first unread message

Pavel Stehule

unread,
Mar 23, 2026, 4:05:46 AM (24 hours ago) Mar 23
to PostgreSQL-cz
Ahoj

Mám pocit, že se konečně začínají objevovat extenze, které využívají Postgres Table Access Method API (toto API umožňuje definovat nové formáty pro uložení tabulek). I když příkaz `create access method` je v Postgresu od 9.6 (rok 2016), zatím jsem neviděl volně dostupnou extenzi, která by nebyla experimentální nebo nebyla v nějakém enterprise uzavřeném balíku (https://www.enterprisedb.com/docs/pg_extensions/advanced_storage_packhttps://docs.percona.com/pg-tde/index.html )

Storage ZED a ZHEAP jsou asi už definitivně mrtvé. Nicméně asi dobře posloužily jako proof concepty.

Oriole https://github.com/orioledb/orioledb je v betě, ale stále není doporučené jej používat v produkci. 

sorted heap je určitě zajímavá záležitost https://github.com/skuznetsov/pg_sorted_heap

pg_duckdb https://github.com/duckdb/pg_duckdb - zatím jsem nezkoušel (zkoušel jsem duckdb), nicméně pro analytiku to vypadá jako super řešení

https://github.com/MasahikoSawada/pgroad - archivní read only komprimované tabulky přijde mi to jako zajímavá záležitost. 

Aktuálně si hraji s extenzí csv_tam (autor Alexey Gordeev). Používám svůj fork https://github.com/okbob/csv_tam, jelikož originální kód nebyl přeložitelný vůči 18 a 19. Kód je spíš minimální technologické demo - rozhodně to není použitelné pro praxi, nicméně to ale může demonstrovat můj nápad, který by se mohl někomu hodit.

Postgres nemá autonomní transakce. Hodily by se, a chybí, když se portují aplikace z Oracle. Pokud vím, tak se v 99% používají pro logování chyb, případně pro notifikaci (do ukončení transakce jakékoliv zápisy nejsou vně viditelné - zápis v autonomní transakci je viditelný okamžitě po dokončení autonomní transakce). Po zachycení chyby, chceme zapsat do logovací tabulky a chybu reraisnout - a to bez autonomních transakcí nelze. 

S TAM API vlastně lze napsat crash safe "netransakcní" storage. Pokud by byl append only, tak by měl podobné chování jako běžný zápis do logu. Je možné napsat online komprimaci, online šifrování, je možné napsat podporu indexace. A díky partitioningu (na denní bázi) je možné řešit retenci - a teoreticky si dovedu představit i řešení retence (a transparentního partitioningu) interně bez použití deklarativního partitioningu v Postgresu (což by se hodilo v prostředí, kde by zámky mohly být problém).

Po 30 letech se dostávám k poznání, že crash safe netransakční engine, kde data budou "definovaným" způsobem mizet může mít smysl. 

Pavel





Reply all
Reply to author
Forward
0 new messages