Які правила визначають, коли SQL Server використовує CTE як "огородження для оптимізації"?

Нещодавно Брент Озар опублікував публікацію, в якій детально описував деякі відмінності між SQL Server і PostgreSQL:

Дві важливі відмінності між SQL Server і PostgreSQL

Перший момент ("CTE - це огорожі для оптимізації") привернув мене до уваги, тому що очевидно, що в наведеному прикладі SQL Server поєднує CTE та основний запит разом і оптимізує його як єдиний запит (на відміну від протилежної поведінки в PostgreSQL).

Однак така поведінка здається суперечкою прикладів, які я бачив в інших блогах та навчальних класах, де SQL Server розглядає CTE як огорожу оптимізації, що дозволяє краще використовувати індекси, кращу продуктивність тощо. Наприклад:

Кращий спосіб вибору зірки

Отже, схоже, що SQL Server «шанує» CTE як огорожу для оптимізації SOMETIMES. Чи є якісь хороші ресурси, які задокументують конкретний перелік відомих випадків, коли SQL Server надійно вшановує CTE як оптимізаційну огорожу (або протилежну поведінку)?

... перелік відомих випадків, коли SQL Server надійно вшановуватиме CTE як оптимізацію

Будь-який такий перелік покладається на спостережувану поведінку, без гарантії надійності.

Оптимізатор запитів SQL Server ніколи не розглядає загальне табличне вираження , як оптимізація забору на собі , хоча деякі конструкції явно важко оптимізувати поперечнику. Рекурсивні КТЕ є хорошим прикладом цього.

CTE трактуються дуже подібним чином до представлень / вбудованих функцій / підзапитів / похідних таблиць і вкладені в запит. Будь-яка спостережувана поведінка «огорожі» залежить від того, що оптимізатор або не може, або вирішив не робити оптимізацію через цю принципову проникну межу.

Взагалі кажучи, чим простіший і більш "реляційний" CTE, тим більше шансів на те, що оптимізатор зможе переміщати біти.

Були запропоновані, але ще не реалізовані функції, які дозволили б оптимізатору врахувати або змусити його матеріалізувати "результат" CTE.

• Оптимізатору слід враховувати матеріалізуючі результати СТЕ
• Підказка щодо додаткового запиту: OPTION (MATERIALIZE (cte_name, ..., n)

Тим часом найпоширенішим вирішенням є явна матеріалізація проміжного результату, встановленого у тимчасовій змінній таблиці або таблиці. Це, очевидно, вимагає сценарію, не обмеженого однією заявою.