Продолжая разговор, об упрощении дерева запроса, начатый в предыдущем посте, рассмотрим еще один интересный случай упрощения.
Комментарии к записи Забавный случай упрощения соединений 2 отключены 
Недокументированная команда dbcc csindex
По мере подготовки докладов на тему Columnstore индексов наткнулся на интересную недокументированную команду dbcc csindex. Никакой информации по ней нашел, по этому поделюсь тем что удалось выяснить самому.
Ошибка вычисления селективности для предикатов с isnumeric
Недавно на одном из форумов был задан вопрос о том, почему при добавлении в запрос условия isnumeric(column)=0, запрос начинает выполняться очень медленно. Изучение этой ситуации привело к интересным результатам.
RowGoal и неравномерное распределенных данных
На написание этой заметки меня подвиг доклад Алексея Эксаревского на 24 hours of PASS про наиболее часты причины ошибок в оценке кардинальности. Те, кто не видел этот доклад могут ознакомиться с ним на techdays. Алексей рассказывает о возможных причинах неправильных оценок кардинальности (или количества строк), из-за чего оптимизатор выбирает неудачный план запроса. Наиболее интересным и
Оптимизатор (недокументированное): Отключить правила преобразования в отдельном запросе
Многие, кто интересуется внутренним устройством оптимизатора, уже наверняка знают, что такое правила преобразования и то, что их можно отключить в сессии при помощи dbcc ruleoff/ruleon. В этой короткой заметке мы посмотрим на недокументированный хинт, который позволяет отключать правила преобразования в отдельно взятом запросе. Прим: Те, кто не знают про правила преобразования, но интересуются, могут обратиться
Оптимизатор (ч.4): Optimization: Full Optimization: Search 1
Optimization: Full Optimization: Search 1 В данном разделе: — update statistics with row_count, page_count; — преобразования memo; — параллельный план; Данная фаза, называется также Quick Plan. Как мы уже говорили, запросы могут миновать стадию Transaction Processing (search 0), и сразу перейти к этой фазе, если в запросе менее трех таблиц. Также эта фаза примечательна
Оптимизатор (ч.3): Optimization: Full Optimization: Search 0
Optimization: Full Optimization: Search 0 В этом разделе: — определение стадий оптимизации, которые проходит запрос; — структура для поиска альтенатив memo; — оператор Apply lookup в nested loops join; — оценки и вычисления селективности запроса с несколькими предикатами; — стоимость операторов; — Rebind, Rewind, RowGoal; — просмотр начального и конечного memo; — выходное дерево физических
Оптимизатор (ч.2): Optimization: Trivial Plan Optimization
Optimization: Trivial Plan Optimization В этом разделе: — применение правил преобразования; — особенности стадии trivial plan; — почему загружается статистика; — как пропустить фазу поиска тривиального плана (upd) Итак, мы получили наше упрощенное дерево. Но как оптимизатор догадался его упростить, что именно сделал. Разберемся. Для начала, немного теории.
Оптимизатор (ч.1): Введение, Optimization: Simplification
Введение В этом разделе: — обзор; — упрощение, исключение противоречий и лишних соединений; — просмотр дерева логических операций; В данной заметке рассматриваются некоторые механизмы работы оптимизатора. Она будет интересна тем, кто хочет больше узнать о процессе преобразования запроса в план запроса, который и будет передан серверу на выполнение. Многие средства, используемые в заметке — недокументированны,