ВЫБРАТЬ
    СУММА(ПродажиОбороты.КоличествоОборот) КАК КоличествоОборот
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачДата, &КонДата, , ) КАК ПродажиОбороты
ГДЕ
    ПродажиОбороты.Склад В ИЕРАРХИИ(&Склад)
    И НЕ ПродажиОбороты.Контрагент В ИЕРАРХИИ (&Контрагент)

3 секунды.

ВЫБРАТЬ
    СУММА(ПродажиОбороты.КоличествоОборот) КАК КоличествоОборот
ИЗ
    РегистрНакопления.Продажи.Обороты(
            &НачДата,
            &КонДата,
            ,
            Склад В ИЕРАРХИИ (&Склад)
                И НЕ Контрагент В ИЕРАРХИИ (&Контрагент)) КАК ПродажиОбороты

11 секунд.

Как так-то?

(0) Видимо, хреново работает сравнение вида "Склад В ИЕРАРХИИ (&Склад) "

Покажи результаты сравнения, в случае, когда " И НЕ Контрагент В ИЕРАРХИИ (&Контрагент) " в скобках и когда в условии "где".

ну да наверно логично, это медленная операция применяется только к подобранным записям за период. А вторая при построении таблицы оборотов. А какой период указан?

Это старый прикол

не нужно пытаться использовать В ИЕРАРХИИ в параметрах выборки других таблиц

ВИЕРАРХИИ не является оптимальным оператором.
Лучше сначала получить все элементы, потом засунуть в параметры Вирт таблицы.

Понятно. Спасибо!

Сделал 3 запроса. Двумя получил список контрагентов и складов.

Разница между этой громоздкой конструкцией и первым запросом всего 15%, кода получилось значительно больше. :-(

У вас сложная структура складов?

И что тебе с того кода? Установлена некая граница на количество символов в текстах запросов?

(8) Хм. Раньше об этом не задумывался.

Посмотрел. Да, больше 1000 складов. :-()

(0) А сколько запрос записей выдает, миллионы?

(9) Ждал значительного изменения скорости.

3-й запрос покажите.

(11) Да нет. Где-то в районе 20'000.

(10) сколько уровней макс?

Ну почему-почему, в первой ты в Обороты() отбор установил, во второй нет

(16) может, наоборот? :)

(0)
Могу ошибаться но есть мнение:
Конструкция "В иерархии" на уровне MSSQL выполняется следуюшим образом : сначала 1С - формирует некую ВТ, куда выбирает элементы согласно структуре иерархии, а потом происходит соединение с таблицей, на которую вы накладываете это условие.
Получается когда вы ставите эту конструкцию в условие виртуальной таблицы - происходит неявное соединение с подзапросом (Формирования Вирт. таблицы Обороты), из-за этого MSSQL может некорректно оценивать текущую статистику и формировать не самый быстрый план запроса.

Если же вы выносите это условие в условия "Где" - у вас сначала формируется Виртуальная таблица с оптимальным планом , а потом на неё накладывается фильтр.
но т.к. неявного соединения с подзапросом отсутствует - виртуальная таблица строится по оптимальному плану. и это быстрее.

+ (18) в догонку
https://its.1c.ru/db/metod8dev#content:5842:hdoc

(17) ну точняк, наоборот
Короче как мне кажется, если простым языком, то это из-за двух условий в виртуальной таблице

Слишком все неопределенно. Я бы проверил регламенты SQL, итоги, агрегаты. Если это стандартная УТ10/УПП, то там вроде нет измерения Склад в РН Продажи, проверить бы, установлено ли там свойство Индексировать измерения, если оно добавлено. А то может оно в итоге не включено или это вовсе реквизит.

(21) думаю чтобы внести определенность , было бы круто планы скуля посмотреть обоих запросов.