Нашёл ситуацию, когда запрос к ВТ Обороты выполняется в 3 раз медленнее, чем запрос на языке запросов 1С.

Вкратце:

Когда у регистра стоит флажок "Быстрая обработка движений", в таблицу движений добавляются поля DATE_TIME_IDDOC, IDDOCDEF и индекс DATETIME. ВТ Обороты для отбора по периоду использует DATE_TIME_IDDOC и попадает в индекс DATETIME. Всё красиво.

Когда флажок "Быстрая обработка движений" не стоит, но стоит флажок "Отбор движений" у любого измерения/реквизита, добавляются те же поля и индекс вида

CREATE UNIQUE INDEX [VIAxxx] ON [dbo].[RAzzz]([SPxxx], [DATE_TIME_IDDOC], [LINENO_], [ACTNO]) ON [PRIMARY] 

ВТ Обороты для отбора по периоду использует DATE_TIME_IDDOC и, при отсутствии отбора по SPxxx, не попадает в индекс VIAxxx.

Результат:

• Запрос с присоединением _1SJOURN и отбором по _1SJOURN.DATE_TIME_IDDOC - 1 секунда.
• Запрос на языке запросов 1С - 3 секунды.
• Запрос к ВТ Обороты - 10 секунд.

Предлагаю эту "фичу" исправить. Ну, или, хотя бы задокументировать.

P.S. А потом я выпил ещё фанты, и тормознул 1С++...  

Предлагается принимать решении о присоедиении журнала не по наличию поля DATE_TIME_IDDOC,
а только по флажоку "Быстрая обработка движений".

Но, если все же будет фильтр по измерению/реквизиту, план выполнения будет менее эффективен, т.к. не будет использован индекс VIAxxx.

Вопрос: можно ли этим пренебреч? Иначе нужно анализировать наличие фильтра