CTE je ohledně práce s katalogem gratis. Na druhou stranu nemá statistiky (a proto je gratis) - a co je občas výhodou, občas nevýhodou - v postgresu je implementováno jako bariéra pro optimalizátor - nepřenáší se odhady - https://blog.2ndquadrant.com/postgresql-ctes-are-optimization-fences/.
CTE dle mého skromného názoru by melo byt zakázáno. Když vidím SQL co je schopen zplodit analyst a pak se divi, že má dotaz běžící několik hodin a ani mu to nepřijde divný a špatný.... naposledy jeden zplodil cte s několika biliony rows a v podstatě nám odstřelil tempdb (mssql ) poté co narostla o 1.5 TB. nemluvě o tom, že jsme ho omylem zaradili do špatné skupiny a neaplikoval se na něj resource governor a granted query memory byla přes 500GB RAM (ano není to překlep, máme 3 TB RAM na každém sql node )
temp může zabít jakýkoliv kartézák, občas i interně generovaný, když má planner extra špatný odhad - na to nemusí být CTE. Na větších datech přeplnění tempu může být z nejrůznějších důvodů a vubec by mně to na čemkoliv nepřekvapilo. Od toho jsou timeouty, případně limity na temp files na pg. Dotazy, které generují BI tooly jsou občas síla. Dostal se ke mně pomalý dotaz na pg .. explain měl 3MB.
Tak o preplneni žádná. ale v tomhle pripade se zadny kartezak nekonal. To jen analyst (rozumějte člověk) napsal CTE s jedním dost špatným derivovaným pocitanym sloupcem aby toho nebylo málo tak to ještě groupnul pomocí case statementu a jako třešničku na dortu to pak v následujícím CTE joinul přes ten computed column s jinou tabulkou opět přes computed value. takže plan s column store vypadal asi tak, že místo v batch mode to celé běželo row by row.
Default timeout to sice řeší ale jen do okamziku, kdy ho změníte v connection stringu a dotyčný bohužel ještě vygooglil hinty a změnil i MAXDOP (degree of parallelism)
ale jak říkám toto je z mssql světa, ale principiálně stejné všude.