Názory k článku PostgreSQL 19: zmenšení tabulek pomocí REPACK bez obav

Vyborne citanie, toto su asi jedine clanky co na root precitam cele pretoze je to o tych nerd detailoch ktore mame radi.
Nesuhlasim iba s vetou: "Má svoje limity, které je dobré znát, a rozhodně nemůže ve všech ohledech (ve větším rozsahu) nahradit Redis, MySQL ..." ja som si uz asi 15 rokov isty ze dokaze nahradit MySQL uplne bez problemov ;-)

Tak jedna funkcionalita co Postgresql nemá je zmíněná i v článku - nepodporuje to multimaster.

MySQL je dlouhodobě optimalizovaná na intenzivní provoz extrémně krátkých transakcí pokud možno přes primární klíče. MySQL se také bude lépe chovat, pokud budete mít širší tabulku, na které je hodně indexů, a kterou často aktualizujete.

A teď záleží na tom - jak je ta tabulka široká, kolik máte RAM, jak máte rychlé disky, a co znamená "často". Jsou aplikace, které dělají vyšší desítky až stovky tisíc update za sec nad jednou tabulkou. U takových aplikací narazíte na limity hw výrazně dříve s Postgresem než s MySQL. Takových aplikací nebude moc, ale existují.

Poslední dva roky vidím u zákazníků problém s výkonem IO. Po migraci do cloudu zjišťují, že pořídit si stroj s dost IOPS je dost drahá záležitost. Takže znovu se naráží na limity IOPS. Je ale pravda, že to bývá spíš v syntetických benchmarcích, kterými dodavatel dokládá dostatečný výkon než z provozu.

SQLý článok. Vďaka.

Jak je to s tou datovou integritou v PG 19 z hlediska upgrade? Pokud jsem upgradoval na 18, tak jsem musel nejdrive zapnout integritu na starsi verzi a teprve pak bylo pouzit pg_upgrade s variantou link. Idealni scenar je upgrade bez integrity a pak vyuzit tu zabudouvanou, co to prevede sama za provozu. Zvladne to pg_upgrade sam, nebo se budou muset delat mezikroky?

Co myslite datovou integritu? Ta 100% nejde vypinat nebo zapinat.

Nemyslite spis checksumy na datovych strankach? V 18 se menilo vychozi nastaveni z off na on. Je mozne, ze pokud jste delali upgrade na 18 a udelali jste si instanci s defaultnim (novym) nastavenim, tak to mohlo delat problemy. Resenim take bylo vytvorit instanci s vypnutymi checksumy. Pokud ale uz je mate zapnute, tak v 19 se uz nic nemeni. Pozor datova integrita a kontrolni soucty nejsou totez. pg_upgrade tohle zvladnout nemuze, protoze pouziva predem existujici instance - jak tu do ktere migrujete, tak tu starou.

Jo, myslel jsem checksumy. Mame jeste spousta <18 verzi, ktere se budou nekdy migrovat a vyplati se s tim pockat na 19.
No jo, ale ta operace je tak trochu ...
instalace PG 19 -> vypnout checksum conf -> pg_upgrade(cluster) -> start -> zapnout checksum v sql -> zapnout checksum v conf
Asi takhle?

checksumy datových stránek se nezapínají konfigurací. Je to vlastnost clusteru - a zapíná se nebo vypíná v okamžiku inicializace clusteru - příkaz initdb nebo offline příkazem pg_checksum. Do 17 se checksumy v initdb zapínaly `--data-checksums` - od 18tky jsou zapnuté by default, a naopak můžete si je vypnout `--no-data-checksums`.

Patrně děláte upgrade skrz nějaké skripty - nemáte Debian? Tam je to všechno owrapované a schované do jednoho kroku - možná tam ta volba `--no-data-checksums` pro 18 (pro skript) bude také.

19 bude zveřejněná na přelomu září/října. Teď ještě není ani beta - jen se dokončil cyklus, kdy je možné přidávat novou funkcionalitu - takže teď se hodí pro neprodukční testování. Do produkce tak cca za půl roku. Teď bych šel do 18tky, ale při inicializaci bych si vypnul checksumy

https://manpages.debian.org/testing/postgresql-common/pg_upgradecluster.1.en.html viz --no-data-checksums

Pokud byste měli dotazy ohledně Postgresu, tak jedno z dobrých míst, kde se zeptat:

https://groups.google.com/g/postgresql-cz?hl=cs

Jo, mate pravdu, stihl jsem pozapomenout, jak jsem to vlastne delal - tedy pomoci prikazu na vypnute instance PG a ne v konfiguraci. Takze se mi fakt vyplati nedelat upgrade na 18 a pockat az na tu 19, nebot preskocim ten nutny, casove narocny krok s prepocitanim checksum.