Vlákno názorů k článku
Tahák pro PostgreSQL od Program - V prvé řadě díky za skělé pdf. Zajímalo...

Tohle téma jsem ještě před chvílí řešil s Tomášem Vondrou - já doporučuji jako min 5 min, Tomáš 15 - což je CHECKPOINT vynucený naplněním segmentů transakčního logu. Vycházím z předpokladu, že čím je častější CHECKPOINT, tím bude rychlejší neboť se bude zapisovat méně dat (tento předpoklad nemusí být pravdivý, pokud např. opakovaně aktualizujete záznamy, které se vyskytují na stejné datové stránce). A zápis menšího objemu dat není taková bomba (checkpoint storm) pro IO - nemusíte mít potom tak velké latence dotazů.

Realita je složitější - každá aplikace se chová trochu jinak, používá se různě rychlé IO, různě nakonfigurované OS, různě se chovající souborové systémy. A navíc existuje proměnná checkpoint_com­pletion_target, která určuje jak intenzivně se mají zapisovat špinavé datové stránky na pozadí - tudíž i když máte relativně dlouhý interval mezi CHECKPOINTy, tak Postgres tiše zapisuje datové stránky na disky a snaží se eliminovat špičky http://www.depesz.com/2010/11/03/checkpoint_completion_target/

Jinak o efektivní nesekvenční write traffic by se měl postarat filesystém a cache filesystému - nicméně pořád ještě hrozí, i když už méně než před několika lety, riziko checkpoint stormů (kdy CHECKPOINT zahltí IO) - tuplem v případě dlouhých intervalů pro CHECKPOINTy a velkého množství shared_buffers.

Závěr - častější CHECKPOINTy nemusí být optimální z pohledu počtu zápisů, ale je to bezpečnější z pohledu latencí příkazů - pokud jsou ale příliš často, tak je to špatně - a je potřeba to řešit.

poznámka - u novějších verzí mohu zvyšováním checkpoint_com­pletion_target a zvyšováním checkpoint_timeout dosáhnout vyhlazení špiček, což bych na malém intervalu nedosáhl - ale to už se musí řešit pro konkrétní aplikaci a konkrétní konfiguraci po relativně důkladné analýze chování aplikace.