Чем на оптимален такой запрос?
 

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

СГРУППИРОВАТЬ ПО
РеализацияТоваровТовары.Номенклатура,
РеализацияТоваровТовары.Характеристика) КАК ПодЗапрос
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыОрганизаций.Остатки(, Склад = &Склад) КАК ОстаткиТоваров
ПО (ОстаткиТоваров.Номенклатура = ПодЗапрос.Номенклатура)
И (ОстаткиТоваров.Характеристика = ПодЗапрос.Характеристика)
ГДЕ
ЕСТЬNULL(ОстаткиТоваров.КоличествоОстаток, 0) - ПодЗапрос.Количество < 0

Было бы предпочтительнее построение на временных таблицах?

РегистрНакопления.ТоварыОрганизаций.Остатки(, Склад = &Склад) - суть - запрос для построения виртуальной таблицы по всей номенклатуре. Ограничь.
Далеко не факт что оптимизатор скуля успеет разобраться что у тебя потом левое соединение к короткому списку

2-roma n > А как оптимизатор сумеет "разобраться"? Что такое "короткий список"? Это скоко в удавах?
:)

Мне кажется вообще дурным тоном полагаться на подобные конструкции. Есть же средства прямой оптимизации.
Если, конечно, вообще есть нужда в оптимизации. Зачастую время писания продолжительнее суммарного времени исполнения.

Можно просто товары документа запросом уложить в список, а затем уже запрос по товарам на складе. Но думаю тут мышиная возня, ну будет запрос выполняться 1 сек или 1.2 сек ))

(4) мышиная возня. В случае нормального регистра, да.
(0) Если это реальная проблема, а не тест - смотри закрывается ли регистр и, если sql, - актуальность статистики