я у себя потестил это запрос
у меня тоже seek только по полю period, если есть условие по складу, но выполняется моментально
без условия по складу - по period+Товар

trad писал(а) 06. Октября 2016 :: 10:25:

Это так и должно быть, поэтому с чего оно тормозит не очень понятно.

pavel_tr А попробуй использовать не jeft join, а просто join. Что нибудь поменяется?

pavel_tr писал(а) 06. Октября 2016 :: 12:34:

19c это кошмар. Да и 2 тоже. Сколько у тебя строк в остатках? 
left везде убрал или только там? Остатки нужны на определенную дату? Если нет то можно отказаться от виртуальных таблиц, запрос совсем простой будет.

А ОбратныйРасчетОтТА включен? Я так понимаю что виртуальные таблицы при запросе на дату ТА должны выкинуть 2 лишних джойна.

pavel_tr писал(а) 06. Октября 2016 :: 16:30:

Забыл что это свойство там не доступно ;(
Хотя там все равно внутри recordset...
Попробуй без виртуальных таблиц. 2с ну никак не пригодно для табличного поля. Табличное поле работает отлично, но вот ограничение выборки с такойто по такуюто запись, что должно ускорять работу, не всегда понимает sql сервер и пересчитывает всю таблицу целиком, и это почти всегда медленно.

1с для того чтобы такого не было сделала отдельный регистр остатков (без партий)

Есть у меня убитая конфа где ПартииНаличие вообще почти не закрываются, и чинить это я там не собираюсь... Накреативили разные умники с моим напарником всякое, вот пусть он и чинит...
Для того чтобы подобное работало с приемлемй скоростью врубил индекс по Номенклатуре и вычисляю остаток отдельным запросом при выводе строки ТП. Там мне еще и партии нужны, но по ним индекс я поднимать не стал, хватило по Номенклатуре. Иначе никак не шевелится.

Это табличное поле... т.е. ограничения топ49 то есть, а sql все равно может вычислять все, и только потом ограничивать по топ49 

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