Názor k článku PostgreSQL 12 – bude rok 2019 rokem Postgresu? od Pavel Stěhule - Možná jste přehlédl, že jsem v textu psal,...

Možná jste přehlédl, že jsem v textu psal, že pokud je relace referencovaná více krát, tak automaticky dojde k materializaci. Tudíž problémy s random() nebo clock_timestamp nemohou nastat. Automatický inline je pouze tehdy, když je relace použitá pouze jednou.

ANSI SQL vůbec nic neříká o optimalizaci a inlining jednou použité reference mně osobně dává větší smysl než materializace. Vývojáři této funkce spíš z jednoduchosti a konzistence implementace inlining vůbec nebrali v potaz - a časem se používání nerekurzivního CTE v Postgresu stalo určitým typem hintu - v podstatě jediným jednoduchým způsobem, jak si vynutit materializaci, a případně jak zahodit odhady, pokud byly chybné. Inlining se v tomto kontextu vůbec neuvažoval - v případě, že by chtěl někdo inlining, tak prostě napsal derivovaný poddotaz.

Všechny jiné databáze ovšem zvolily jinou strategii - a jelikož se v posledních 5 letech intenzivně začalo migrovat z těchto databází do Postgresu, tak se začalo ukazovat, že ta jednoduchá implementace "materializace vždy" je příliš jednoduchá - a nedává smysl (pro pouze jednou referencované CTE). To nikdo nerozporoval - problém byl jen, jak minimalizovat impakt na stávající uživatele - jak moc porušit svá pravidla - defacto se jedná o hint. Drtivé většině uživatelů by inline měl spíše pomoc, ale určitě budou existovat uživatelé, kteří CTE použili kvůli zahození odhadů, a těm se výpočet může zhoršit.

Nevím o tom, že by ve standardu bylo něco o garanci pořadí provedení CTE. To i při materializaci pokud tam nemáte závislosti, tak se teoreticky může vykonávat v náhodném pořadí - teoreticky i např. v jiném procesu, kdy se bude synchronizovat pouze výsledek (což zatím není implementováno, ale bere se to jako možnost).

Porušení zpětné kompatibility je vždy problém, a vývojáři to neberou na lehkou váhu. Vždy někoho naštvete - noví uživatelé preferují co nejmodernější implementaci (optimalizaci) pokud možno kompatibilní se světem. Stávající uživatelé preferují kompatibilitu. V tomto případě by asi nejčastějším nepříjemným efektem mohlo být zpomalení některých dotazů (ale to je v každé verzi, že cca 2-5% dotazů je v nové verzi pomalejší v důsledku jiné optimalizace, jinak počítaných statistik, odhadů). Počítat jinak by to nemělo, pokud ano, tak bych to spíš než na bugu viděl jako zákaznický kód, který se pohybuje v zóně nejednoznačně definovaného chování, který v nějaké verzi fungovat může, ale v další nemusí (v každé verzi Postgresu se hodně mění optimalizátor, executor, ..)