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.

Ak MySQL je na nejaky problem lepsie riesenie ako PostgreSQL tak na 100% viem garantovat ze existuje este uplne ine riesenie ktore je este lepsie ako MySQL.

Co se vlastně snažíš říct, je to, že je MySQL špatná databáze?

Neviem ci zla len nevidim kde ju pouzit. Ak nie som lepic JS kodu a word press modulov ktore vyzaduju MySQL tak nevidim miesto kde ju pouzit. Ak potrebujem SQL databazu pouzijem PostgreSQL. JSON, full text search, podpora platforiem, ... vela z toho ma aj MySQL ale vzdy v limitovanejsej podobe nez PostgreSQL. A ked sa dostaneme naozaj do stadia ze PostgreSQL nestaci a mozno by MySQL bola trochu rychlejsia tak tam viem nasadit uplne iny typ DB alebo technologie ktory bude nasobne rychlejsi aj ako MySQL.

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.

Teď v nedávné době proletěla internetem zpráva, že PostgreSQL má výkonnostní problém na Linuxu 7.0. Příčinou je změna defaultního scheduleru v kernelu. Respektive odstranění jednoho z existujících a nahrazení jiným, novým. Přidali nový scheduler a odebrali jeden stávající. Ten starý tam měli ještě chvíli ponechat, ať si ten nový lidé dostatečně vyzkouší.

PostgreSQL si alokuje velký buffer v paměti a při přístupu k němu používá spin lock. Při použití starého scheduleru bylo vše v pořádku, vždyť PostgreSQL bylo léta odladěné a předpokládalo nějaké chování kernelu. S novým schedulerem kernel přepíná vlákna častěji. Například i v okamžiku, kdy jedno vlákno zrovna drží zamknutý zámek a řeší soft page fault (minor page fault). Ostatní vlákna dostanou příležitost běžet (se starým schedulerem nedostali) a jediné co mohou dělat, je točit se na spin locku. A plýtvat tak výkonem CPU.

Řešením je zapnout large pages / huge pages. Tím se razantně sníží počet page faults.

Možná by to stálo za zprávičku.

Zdroj například tady: https://read.thecoder.cafe/p/linux-broke-postgresql a nebo tady: https://mydbanotebook.org/posts/postgres-performance-regression-are-we-there-yet/

https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqkn37qzlvvzgad5hfd7ut@xv4cihno76wu/

Andres Freund se k tomu vyjádřil a nevypadá to jako vážný problém. V případě, že máte relativně málo paměti, a málo shared_buffers (hodnotu určujete vy), tak se ten problém neprojevuje, a pokud máte vyšší shared buffers (vyšší desítky GB), tak by se mělo používat huge pages.