Возник тут у нас спор с коллегами на такую тему:

Я утверждал что условия в секции ГДЕ накладываются на результат соединения таблиц. Т.е. сначала таблицы соединяются левым или любым другим соединением, а уже на результат соединения накладывается условие.

Однако коллега утверждал иное и продемонстрировал это на примере:

ВЫБРАТЬ Т1.Рес1, Т2.Рес1
ИЗ РегистрСведений.хх КАК Т1
  ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.хх КАК Т2
  ПО Т1.Изм1 = Т2.Изм1
    И Т1.Изм2 = т2.Изм2
ГДЕ
  Т2.Изм2 = "блабла"

в результате выполнения запроса профайлер показал что план запросов был такой:
две выборки с index seek с отбором P1 = "блабла"
и соединение nested loops этих двух таблиц

и вот получается что он прав.
но возможно, это частный случай?
если сравнивать с null Т2.Рес1, то мы видим обратную картину, т.е. сначала соединение таблиц, и уже в конце фильтр по null.

кто из нас прав-то? меня учили что ГДЕ накладывается на результат соединений...

>но возможно, это частный случай?

это общий. п.э. все пихают "где" в условия соединения

(1) "п.э." это что?

полиэстр

О_о

т.е. например сумма тоже пихнется в условия соединения?

ГДЕ
  Т1.Рес1 + Т2.Рес1 = 0

(2) поэтому

так отработало потому что соединение на равенство по полю отбора стоит.

В SQL запросе ГДЕ выполняется после соединения. Тут или 1С при трансляции изменило запрос, или оптимизатор догадался.

где выполняется после соединения, на результат

*накладывается на результат

(0) "а уже на результат соединения накладывается условие." - с т.зр. логики - всё так, но с т.зр. оптимизатора sql - почему бы и раньше не наложить условие для ускорения.

(11) Да, именно тот случай

(0) Неправы оба. Просто в данном случае СУБД построила запрос именно так. В другом случае она может выбрать другой план запроса, если, например, отбор "P1 = "блабла"" не будет иметь достаточной селективности.

Прав из вас двоих был бы тот, кто сказал, что в результате такого запроса ты всегда получишь внутреннее соединение.
А уж как именно СУБД его получит, - зависит от СУБД и конкретной ситуации.

но сознательно вот так (0) для получения внутреннего соединения делают только польностью оформленные законченные мудаки.
Потому что это грабли для сопровождения - легко можно не заметить этой подковырки и долго не понимать, что происходит.

если физический порядок выполнения не влияет на результат, то оптимизатор может переставлять операторы как угодно. в (0) вообще внутреннее соединение и какой-нибудь мерж/хэшмач может быть.

(0) посмотри, что будет с планом запроса, если Т2.Изм2 будет булево и не индексировано, например