ВЫБРАТЬ
    Контрагент.Ссылка КАК Контрагент
ПОМЕСТИТЬ ВТ
ИЗ
    Справочник.Контрагент КАК Контрагент

ИНДЕКСИРОВАТЬ ПО
    Контрагент
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ПоступлениеДенег.СуммаПоступления КАК СуммаПоступления
ИЗ
    Документ.ПоступлениеДенег КАК ПоступлениеДенег
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ КАК ВТ
        ПО ПоступлениеДенег.Контрагент = ВТ.Контрагент
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ПоступлениеДенег.СуммаПоступления КАК СуммаПоступления
ИЗ
    Документ.ПоступлениеДенег КАК ПоступлениеДенег
ГДЕ
    ПоступлениеДенег.Контрагент В
            (ВЫБРАТЬ
                ВТ.Контрагент
            ИЗ
                ВТ КАК ВТ)

Если поле контрагент документа не индексированное, есть ли разница в быстродействии запросов 1 и 2?

Вопрос возник в курилке, я обычно использую соединение, а коллега оператор В, так прикинули что и там и тут будет перебор, но в моем случае есть индекс по маленькой таблице, на что коллега парировал что согласно рекомендаций 1с индекс будет иметь смысл только в большей таблице при внутреннем соединении

взяли да замерили производительность того и другого варианта, чего спорить-то...

Про замер была идея, но вопрос интересен не с экспериментальной точки зрения, а с точки зрения теории. Если даже узнаем что лучше, вопрос почему останется.

(3) если брать в теории, то 1С не рекомендует использовать вложенные запросы и стараться максимально обходиться без них. но у этой теории есть много противников...

Тут будет хороша аксиома Эскобара.

Индексировать ВТ не нужно почти никогда.

хотя именно в твоем запросе, я никакого криминала в использовании вложенного запроса не вижу...

Экономить нужно не не только время процессора но и лично свое время. Вложенные запросы труднее отлаживать. Поэтому первый вариант предпочтительнее.

(5) В левом соединении когда временная таблица справа, нужно - будет эффективнее
    во внутреннем соединении когда временная таблица большая - тоже будет эффективнее это если верить 1С https://its.1c.ru/db/v8std/content/658/hdoc

вот статейка на эту тему...
http://catalog.mista.ru/1c/articles/1218921/

Я для себя выделил 3 правила:
1) Любая Виртуальная таблица, к которой будет соединение (явно, или через точку) - выбирается в ВТ.
2) Фильтрую ВнутреннимСоединением вместо В()
3) Если нужно соединить больше 3 и более таблицы - соединеняем через Временную таблицу сначало 2-ые 2, потом еще с одной.

(8) Нет.
Индексы могут помочь только для Соединения на неравенство.

(9) спасибо за статью интересная тема

(11) Не понял почему, ведь индексы эффективны в первую очередь на равенство, а неравенство это тоже равенство с НЕ

эта, гуру, заканчивайте путать виртуальные и временные таблицы. глаза режет...

(9) Вывод временные таблицы индексировать не нужно в 99%, потому что индексы хороши когда построил индекс и потом часто им пользуешься, а во временной таблице использовал один раз и строй заново.
День прошел не зря.

(15) Нет.
Там дофига ньюансов, общий смысл в том, что большая ВТ - плохо само по себе, а маленьких реальных таблиц и нет обычно.

(0) А теперь то же самое, но на реальной задаче.

(0) а так вы свое писькомерство на форум решили вынести, еще и курилка... тут не до таблиц, имхо, здоровье важнее.
если серьезно, возьмите да замерьте, посмотрите план запроса.
тема не имеет смысла без объема данных и планов запроса.
от себя:
В для фильтрации не использую, ибо был случай в практике, что такое В породило 180 секунд ожидания, вместо 3х на inner join'е
ну и там разименования не надо юзать, смотреть где у нас индексы есть и все такое.

(0)
В общем случае разные результаты. Оператор "В" не множит строки

С какой-то версии платформы 8.3 "В" преобразуется в inner join

+(20) Ну не всегда а если в "В" свыше определенного количества элементов

(3)Ну если интересует именно с точки зрения теории, то достаточно посмотреть типовые конфы - и там в 99% случаев будут временные таблицы.

(1) Коллега прав. Если выборка маленькая, то лучше отказаться от индекса.

(20) а пруф будет?
в общем случае это разные и не взаимозаменяемые операции

(24) можете проверить в профайлере- 10000 элементов должно хватить для "превращения"

(0) 1. Разница есть (странно, если бы её не было, это два разных плана запроса)
2. У какого способа преимущество в быстродействии - зависит.

Интересно сравнивать когда В &МассивЭлементов,то есть чистое В,а не в подзапросе.

Ну и у sql хранение таблиц по кластерному индексу,то есть таблица будет индексирована по полям,когда будет сохраняться.

(25) Неа
http://prntscr.com/z076qe

(27) Точно также, IN
Но при этом создается индексированная ВТ и туда Bulk Insert загоняется массив.
http://prntscr.com/z07ou5
http://prntscr.com/z07qwd

Индекс при этом бессмысленен.

(20) Это, скорее всего,  про списки/массивы в параметрах.
Т.е если условие типа  ГДЕ Спр.Ссылка в (&СписокКонтрагентов), то при большом количестве элементов, список не литералами вставляется в запрос СУБД, а во временную таблицу, которая джойнится.

если же условие вида  ГДЕ Спр.Ссылка В (ВЫБРАТЬ Различные Контрагент ИЗ Документ.Поступление) - сомневаюсь что 1С будет преобразовывать условие IN() в JOIN

(31) + >> во временную таблицу, которая джойнится.

Судя по (30), в этом случае все равно IN()
Но почти уверен, что на ранних версиях 8.2 видел именно JOIN, и "поштучные" Insert`ы. Могу ошибаться)

>>Т.е если условие типа  ГДЕ Спр.Ссылка в (&СписокКонтрагентов), то при большом количестве элементов, список не литералами вставляется в запрос СУБД, а во временную таблицу, которая джойнится.

да, именно, а не когда IN() из ВТ

В нашем случае основная таблица около 82000 строк таблица в операторе IN (порядка 5000)

К сожалению профайлер не доступен, если тупо замерять разницу то ее нет на нашем объеме данных