Отговорът е лесен.
SQL Server не материализира CTE. Той ги вгражда, както можете да видите от плановете за изпълнение.
Други СУБД могат да го приложат по различен начин, добре известен пример е Postgres, който материализира CTE (по същество създава временни таблици за CTE зад капака).
Дали изричното материализиране на междинни резултати в изрични временни таблици е по-бързо, зависи от заявката.
При сложни заявки разходите за писане и четене на междинни данни във временни таблици могат да бъдат компенсирани от по-ефективни по-прости планове за изпълнение, които оптимизаторът може да генерира.
От друга страна, в Postgres CTE е „оптимизираща ограда“ и машината не може да прокара предикатите през границата на CTE.
Понякога един начин е по-добър, понякога друг. След като сложността на заявката надхвърли определен праг, оптимизаторът не може да анализира всички възможни начини за обработка на данните и трябва да се спре на нещо. Например редът, в който да се съединят масите. Броят на пермутациите нараства експоненциално с броя на таблиците, от които да избирате. Оптимизаторът има ограничено време за генериране на план, така че може да направи лош избор, когато всички CTE са вградени. Когато ръчно разделяте сложна заявка на по-малки, по-прости, трябва да разберете какво правите, но оптимизаторът има по-голям шанс да генерира добър план за всяка проста заявка.
