Форма списка справочника "Товары" переписана на прямой запрос на табличном поле с поставщиком данных ODBC. В форме присутствует колонка с остатком по выбранному складу. Часть запроса выглядит так:

FROM $Справочник.Товары as Спр (nolock)
left join $РегистрОстатки.Остатки(
                                   ,
                                   ,
                             Склад = ?ТекущийСклад(14,9)
                                   ,
                             (Товар),(Остаток)
                                                           ) остаток on остаток.Товар = Спр.ID

После открытия периода в начале месяца форма списка "подвисает" при открытии и листании. Вместо моментального отображения информации, примерно минуту выполняется запрос для каждой порции данных. Ночью выполняется обновление статистики и форма снова летает. Всё бы ничего, но объёмы данных выросли и теперь такие зависания могут возникать и в течение дня. Начал разбираться в чём причина. Сделал копию базы, открыл период, статистику не обновлял. Смотрю план выполнения запросов.  С правильной статистикой поиск по кластерному индексу регистра остатков с таким seek predicates: Prefix: [book1_SQL].[dbo].[RG1501].PERIOD; [book1_SQL].[dbo].[RG1501].SP1511 = Scalar Operator('2016-10-01 00:00:00.000'); Scalar Operator([book1_SQL].[dbo].[SC10].[ID] as [Спр].[ID])
А с тухлой статистикой - так: Prefix: [book2].[dbo].[RG1501].PERIOD = Scalar Operator('2016-11-01 00:00:00.000')

Можно ли как-то повлиять на это кроме запуска обновления статистики по расписанию? Сейчас настроил обновление раз в два часа, но она выполняется минут 10 и нагрузку даёт нехилую - не выход это.

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

С тухлой статистикой и без индекс используется один и тот же, про хинт WITH знаю, но тут он, видимо, не поможет.
По порядку таблиц. Это запрос для формы списка справочника. Показывать нужно все элементы. А склад, теоретически, вообще может быть не выбран.
Попробую добавить доп.индекс.

чему равна опция "max degree of parallelism" ?

я использую 1
1с рекомендует 1

интересно увидеть весь план "с тухлой статистикой"

10 минут обновляется статистика по одной таблице остатков, я это и использую. Ночью статистика по всей базе обновляется за 3,5 часа.
rg1501.sqlplan

Да, я это заметил. В копии базы, над которой ставил эксперименты, сейчас запрос снова выполняется быстро, хотя я ничего не делал. И план правильный. Видимо стоимость этой пары планов очень близка