Odpověď na názor

Migrací Postgresu jsem dělal stovky - od dob, kdy se začal používat pg_upgrade, upgrade samotný vždy prošel bez problémů. V posledních letech jsem viděl u zákazníků bezproblémové přechody z 15-16, 16-17, a teď nedávno z 17-18. Neviděl jsem, že by se upgrade podělal.

Viděl jsem, že s novějšími verzemi některé aplikace pro monitoring měly problém - dochází ke změnám systémového katalogu a bez podpory novější verze to samosebou failne. Dnes už spíš výjimečně se narazí na nějaké problémy s kompatibilitou - vzpomínám na přechod na ANSI stringy nebo změna formátu bytea. Téměř vždy se objeví nějaké důsledky práce na optimalizátoru - pár dotazů v aplikaci se chová jinak - pár je rychlejších, pár je pomalejších. Dost problémů je způsobeno tím, že uživatelé po upgrade nepustí ANALYZE. To se dělo hodně kolem 10-12. Měnila se optimalizace CTE, zaváděl se JIT. To se stát může - zvlášť u dotazů, kde jsou špatné odhady. Nicméně rozhodně se to nestává pokaždé - a problémy s optimalizací vám mohou nastat i v provozu nárůstem tabulek (nebo po přidání indexu).

To ale není specifikum Postgresu - to platí pro každou databázi, která negarantuje 100% zpětnou kompatibilitu u optimalizace. U MySQL v 8čkové verzi došlo k razantnímu přepisu optimalizátoru - tam problémů s dotazy muselo být mraky. A co se dívám na release notes MySQL i MariaDB, tak optimalizaci dělají dost změn a dost pochybuju, že by garantovali neměnnost plánů. Jak MySQL tak MariaDB má nyní optimalizaci podobnou Postgresu - u složitějších dotazů dostanete lepší plány - na druhou stranu tam bude vyšší citlivost na statistiky. A ten přepis optimalizace museli udělat, protože ve starších verzích MySQL optimalizace složitějších dotazů nebyla dobrá.

15. 1. 2026, 06:16 editováno autorem komentáře