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

делаю

|ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
|ПО (Накл.ДокументОснование = Заявка.Ссылка
|    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать)
|    ИЛИ Накл.Ссылка = Заявка.ДокументОснование
|    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти))

работает, но оооочень долго
подскажите, как лучше сделать?

убрать левое соединение и написать условие
ГДЕ
Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать)
ИЛИ Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти)

ИЛИ отрубает работу индексов. А если так?

|ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
|ПО (Накл.ДокументОснование = Заявка.Ссылка
|    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать)

ОБЪЕДИНИТЬ ВСЕ

|ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
|     Накл.Ссылка = Заявка.ДокументОснование
|    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти))


+

и перед присоединением таблицы справа неплохо-бы сделать (1)

Таблицы перед соединением неплохо-бы отфильтровать - количество проверок условия соединения равно

(число строк в левой таблице) x (число строк в правой таблице).

И еще вариант во временную таблицу выгрести заявки с условием по операция и через Выбор сформировать поле для связи, потом в основном запросе по этому полю соединять.

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

ГДЕ
Заявка.Операция В (ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать), ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти))

(0) Запрос полностью?

(0) запрос ускорился ???

|ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
|ПО Накл.ДокументОснование = Заявка.Ссылка

ОБЪЕДИНИТЬ ВСЕ

|ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
|     Накл.Ссылка = Заявка.ДокументОснование

...
|ГДЕ
|Заявка.Операция В (ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать), ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти))

|ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
|ПО (Накл.ДокументОснование = Заявка.Ссылка
|    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать)
|    ИЛИ Накл.Ссылка = Заявка.ДокументОснование
|    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти))

УБЕРИ .Ссылка

(3) Вообще говоря не должно отрубать. Планировщик должен сообразить и переписать на union. Но платформа бывает столько накручивает в запросе, что он путается.

(11) -> (2)

отвлекали...
про объединить тоже думала. сам запрос большой, громоздко будет, попробуй сейчас.

(11) http://its.1c.ru/db/v8std#content:2149184307:1 это из стандартов

(10) - а как связывать тогда?
(14) - нет доступа :(

(0) Озвучьте пожалуйста, параметры железа и размер базы данных. Это может многое прояснить.

(15) Да не суть... Главное, чтобы ИЛИ в секции запроса ПО не было. И в левой таблице перед соединением неплохо-бы уменьшить число записей (см. (1)(6)).

(14) Я про Скуль

(11) если ты про скуль, то не обязан.

(15) при указании .ссылка обращение происходит к данным столько, сколько у Вас в запросе будет выводиться Заявка.Ссылка.
Без указания .ссылка тоже будет работать!!!! Проверенно! Производительность увеличиться в разы!

(20)нет, ругается, что не найдено поле Заявка и не найдено поле Накл

(8) когда сделала объединение, да быстро отрабатывает.
только запрос громоздкий.
а если оставлять в соединение таблиц ИЛИ, то сразу начинает тормозить

(4) в вт выгружаю все заявки с видом операции. а дальше не совсем поняла, чего делать

(22) пусть громоздкий будет, стандарты 1С (14) кровью написаны. (23) это не избавит от ИЛИ, игнорирующего индексы

(0) ВЫРАЗИТЬ(<Выражение> КАК <Тип>)

(22) Я вспомнил основы математической логики. Кстати, можно избавиться от ИЛИ не увеличив запрос в размерах:

  Условие А или Б, тождественно условию НЕ (НЕ А И НЕ Б).
  Мысль понятна!?

то есть, условие соединения можно преобразовать к виду

  |ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
  |ПО НЕ (НЕ (Накл.ДокументОснование = Заявка.Ссылка
  |    И Заявка.Операция =    ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Забрать))
  |    И НЕ (Накл.Ссылка = Заявка.ДокументОснование
  |    И Заявка.Операция = ЗНАЧЕНИЕ(Справочник.ВидыОпераций.Отвезти)))

P.S. Не уверен, что сработает, но, очень прошу, отпишись о результатах эксперимента - мне самому интересно.

Требуется пакетный запрос.
1 Запрос будет состоять из двух запросов которые будут объединяться по вертикали(через объеденить).
1.1 В первом Выбираем Заявки у которых вид операции забрать
1.2 Во втором Выбираем накладные у которых основание заявка с нужным видом операции
2. Запрос будет формироваться на основании работы первого запроса(он же пакетный) и он будет возвращать документы основанием которых являются документы из первого запроса. Все. Выполняем пакет. Из первого запроса берем основания, из второго нужные документы. Вроде все просто. Или я что то забыл\не понял?

Никаких или

(27) ОБЪЕДИНИТЬ ВСЕ было уже и дало ускорение (22), теперь надо попробовать (26) - может получится компактный И быстрый запрос

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

(30) Один и тот же запрос 2 раза, только с разными условиями соединения вместо ИЛИ как в (2) - вот и текст запроса растет.

Выбрать Ссылка
Из Документ.Заявка
Где Документ.Операция = Значение(КакоеТоТамЗначение)
ОбъеденитьВсе

Выбрать Ссылка
Из Документ.Накладная
Где
Документ.Основание.Операция = Значение(КакоеТоТамЗначение)

Где тут громоздкость?(за ситаксис ссори) писал на скорую руку из головы

(32) По сравнению с

Выбрать Ссылка
Из Документ.Заявка
Где Документ.Операция = Значение(КакоеТоТамЗначение)
ИЛИ Документ.Основание.Операция = Значение(КакоеТоТамЗначение)

В 2 раза размер увеличивается, а представь, если в исходном запросе уже 200 строк и в 2 раза увеличить его - это уже 400 строк.

Первое решение, все таки более правильное и читаемое и удобное, я бы даже и не смотрел другие варианты. Зачем смотреть в другую сторону, если есть правильный вариант, гляньте на ЗуП, процедура заполнения табеля
http://test-bootst.appspot.com/p/ho5l163f8l146lu (не буду сюда постить эту простыню)

(34) Ладно, будет Profiler под рукой - на простых примерах выложу планы запросов через ОБЪЕДИНИТЬ, ИЛИ и (26).

(34) операция индексирования

|ИНДЕКСИРОВАТЬ ПО
|    Ссылка

кстати, тоже машинное время отнимает. А без ВТ и без ИЛИ используются уже "готовые" индексы.

(22) громоздкий - это 6 экранов, но лучше такой, т.к. быстро отрабатывает. Я вот планирую еще 2 экрана туда добавить, чем писать на один экран и отрабатывает долго.

(26) неа, долго отрабатывает, так же, как с или

(32) я привела только соединение. сам запрос большо и несет в сееб несколько таблиц. если без или, то становится в два раза больше. если с или, то тормозит

в итоге сделала так:

в вт делаем отбор по видам операций

в запросе

  |ЛЕВОЕ СОЕДИНЕНИЕ Документ.Накладная КАК Накл
  |ПО (Накл.ДокументОснование = Заявка.Ссылка)

а в новое поле выдергиваю

|ВЫБОР
|КОГДА (НЕ Заявка.ДокументОснование.Ссылка = ЗНАЧЕНИЕ(Документ.Накладная.Пустаяссылка))
|ТОГДА ЗаявкаЭкспедитора.ДокументОснование.Ссылка
|ИНАЧЕ ЗНАЧЕНИЕ(документ.накладная.пустаяссылка)
|КОНЕЦ КАК НакладнаяОснование
компактно и работает так же быстро, как с объединением

(40) Спасибо! Будем в перспективе делать через ВЫБОР.