Всем привет!
Есть справочник, допустим контрагентов. Нужно выбрать из него только нужных.
Список нужных элементов передается в массиве СписокКонтрагентов.
Т.е. делаем элементарный запрос Выбрать ... ИЗ Справочник.Контрагенты ГДЕ Контрагент.ССылка в (&СписокКонтрагентов)
Но по некоторым справочникам нужна ооочень большая выборка, т.е. в массиве передается очень большое число элементов, а в некоторых справочниках чуть ли не весь справочник.
В этом случае условие: ГДЕ Контрагент.ССылка в (&СписокКонтрагентов)
будет работать не оптимально?
Может быть лучше передавать изначально не массив нужных элементов (этот массив выгружается из результата запроса), а временную таблицу?

>>не массив нужных элементов (этот массив выгружается из результата запроса)
Зачем выгружать из запроса, а потом обратно загружать:)
Поместите во временную таблицу в первом запросе, потом обратитесь во втором в ней же.
Еще возможно проиндексировать по контрагенту..

(0) откройте для себя МенеджерВременныхТаблиц.

(1)  > Зачем выгружать из запроса, а потом обратно загружать:)
Да просто функции, возвращающие массив, давно уже есть и использовались для других целей.
Решил прикрутить их, но увидел, что по некоторым запросам выдает очень большой набор данных, и делать условие ГДЕ наверное неразумно.

(2) Изначально конечно сделал бы через ВТ, но легаси-код... Как говорится, не трогай пока работает

(3) ты либо оптимизируй, либо не трогай пока работает.

(3) >Изначально конечно сделал бы через ВТ, но легаси-код... Как говорится, не трогай пока работает
Если "СписокКонтрагентов" будет 128 элементов, то в запрос будет переданы параметры 1..128.
Если больше 128, то будет создана временная таблица и использовано внутреннее соединение.

(5) Да, больше 128 элементов.
Получается, что переделав на ВТ, ничего особо не выиграю, платформа сама это сделает.
Только код будет смотреться более "правильно"

(6) Да, если при обновлении платформы разработчики 1С сами это количество не изменят.

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

(5) вот, да

(6) На 8.2 (точнее не скажу) операция "создана временная таблица" - выполнялась очень небыстро, т.к. для каждого элемента списка выполнялся отдельный insert values. Но возможно этот момент оптимизнули

(0) >>В этом случае условие: ГДЕ Контрагент.ССылка в (&СписокКонтрагентов)

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

(10) Оптимизировали

(10) bulk insert

(13) insert values будет быстрее транзакциями по 5000 записей

(10) Тормознуто могло быть только если на каждый инсерт была отдельная транзакция

(15) Каждый отдельный insert - это вызов сервера SQL с сервера 1С. Будет на порядки тормознее, даже если сервера вместе через sharedmem, чем одним запросом.

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

(17) это делает сама 1с, или скуль?

(16) А bulk insert это подготовка отдельного файла.

(19) Единственный минус у 1С это тормоза укладывания больших текстовых инструкций.
Быстрее будет использовать сторонние языки

(19) булка всё равно быстрее, даже с учетом затрат на создание файла

(18) 1с