Vlákno názorů k článku PostgreSQL 18: třicet let otevřeného vývoje databáze od miho - Platí i u nových verzí, že je nad...
-
Posledních 15 let určitě není nutné pravidelně používat VACUUM FULL. Je to nejjednodušší kompletní údržba, ale právě vzhledem k zámkům a k faktu, že se znovu buildují indexy, tak se v kritičtějších provozech VACUUM FULL téměř nepoužívá. Paradoxně, občas se s tím ještě v některých firmách setkám, ale je to dané tím, že vůbec netuší, co dělají, a co je potřeba dělat.
Je nutné reindexovat - zvlášť u průtokových tabulek (tam degradace indexů může být rychlá). Reindexaci je ale možné provést za provozu příkazem REINDEX CONCURRENTLY (od 12ky), a dříve CREATE INDEX CONCURRENTLY (8.2 - rok 2006).
V řadě případů se dá potřeba reindexace řešit partitioningem, kdy se místo promazávání dat dropne partišna - a pak není potřeba nic reindexovat.
V 19ce by měl být k dispozici příkaz REORG CONCURRENTLY - což je vlastně VACUUM FULL CONCURRENTLY, který by neměl vyžadovat exkluzivní zámek. Nepředpokládá se, že by to byl příkaz, který by se používal pro pravidelnou údržbu.
Pokud máte potřebu někam ukládat vysokoobrátková data, zvlášť pokud máte nad tabulkama hodně indexů, tak PostgreSQL nemusí být pro Vás ta správná databáze. Nejde jen o nutnost vakuovat tabulky, ale i samotný update bude v MySQL výrazně rychlejší. Existuje extenze OrioleDB, která implementuje nový typ storage, který je navržený pro popsané použití: https://github.com/orioledb/orioledb . Je to ale zatím ve stavu public beta (jejich slovy). Co je mi známo, tak stávající storage v Postgresu se výrazněji upravovat nebude - je odladěný, a i když určitě nevyhovuje každému, tak drtivé většině uživatelů bezproblémově vyhovuje. Do Postgresu se dneska ukládá provozní monitoring kolosů jako je O2 nebo ČEZ. Dovedu si, ale představit a setkal jsem se s použitím, kde bych Postgres nenasadil, kde by MySQL nebo farma MongoDB byla určitě vhodnější.
-
pokud smažete celou tabulku - tak aby v ní nezůstal ani jeden řádek, tak i běžné VACUUM vám zredukuje velikost datového souboru na nulu. Když tabulku dropnete - tak se obsazené místo zruší také - nic nemusíte vacuuovat.
Existují extenze - https://www.cybertec-postgresql.com/en/products/pg_squeeze/ nebo starší pg_repack, které umí udělat totéž, co VACUUM FULL, ale zkrátí exkluzivní zámek na minimum.
Aktuálně nemám žádného zákazníka, který by musel používat VACUUM FULL. Kdybyste měli zájem - napište mi, pavel.stehule@gmail.com - mohu se podívat na vaši db. Takhle od stolu vůbec netuším, co by mohlo být důvodem, proč u vás používáte VACUUM FULL nějak často. Může to být závažný důvod, může to být nějaká blbost, nevím, ale rozhodně je to dost neobvyklé.
může se stát, že vám něco blokuje vacuum - sice běží, ale nic neudělá. Bloatnou vám tabulky, vy si pak odstavíte systém - tím eliminujete i ten blokující proces, a pak to řešíte VACUUM FULL. Je potřeba si ohlídat, že vám vacuum nic neblokuje - pokud ano, tak pak jsou s tím problémy. Vacuum vám může blokovat extrémně dlouhý dotaz, transakce, zapomenutá replikace, nedokončená 2PC transakce, ...
22. 4. 2025, 13:03 editováno autorem komentáře
-
Samozřejmě, nicméně pokud se použije DELETE, tak to bude o dost pomalejší (hlavně, když jsou tam nějaké vazby referenční integrity) a po VACUUM se tabulka dostane taky s velikostí na nulu. VACUUM odstraňuje prázdné datové stránky odzadu. U neprázdné stránky je redukce docela málo pravděpodobná.
Nejsem si úplně jistý, jestli jsou všichni vývojáři schopní používat TRUNCATE. Zvlášť pokud používají nějaké ORM knihovny. Některé aplikace nebo například nastavení provozu je dost divočina.
