Закупки ->Заказы поставщикам ->Создать->По потребностям

формирование заказов по потребностям шаг1 из 5
  выбираю склад и номенклатуру - не много - порядка 80000
нажимаю далее - попадаю на шаг 2 и снова нажимаю далее

Можно пойти покурить

скорость выполнения очень маленькая , после выполнения трассировки по времени исполнения
обнаружил приличную задержку в обработке {ОбеспечениеПотребностей} модуль мененджера

```1c
    Функция ТаблицаЗапасы(Отбор, ТипОтбора, ТаблицаСпособовОбеспечения = Неопределено) Экспорт
    ...
    Сообщить ("Beg "+ТекущаяДата() ); // поставил для
    Таблица = Запрос.Выполнить().Выгрузить();
    Сообщить ("End "+ТекущаяДата() ); // порядка 8 минут
```

Посмотрел в профайлере SQL , запрос конечно дико большой

Какие шаги можно предпринять для уменьшения времени ?
---
Оборудование менять при обнаружении криво написанных запросов затратно. Хотя это неплохой способ нагреть руки , объяснив руководству необходимость смены оборудования, и получив от фирмы поставщика оборудования - оtкат за хороший заказ, ИТ сфера хороша для подобных схем.

Выборка производится из двух смешных по объему таблиц обе порядка 100 тыс записей , другие таблицы не в счет там вообще объемы смешные,
запрос реально кривой, поскольку выполняется несколько минут.

        В другой задаче ( не 1с платформа) имеется порядка 100 миллионов записей , запрос проходит порядка 5 секунд. Правда он состоит из 3 SQL запросов
вместо одного, если соединяю в один - не получаю 5 секунд - получаю несколько минут.

А вот с оптимизацией поиграл.
После того как провел реиндексацию на SQL сервере , по всем индексам , проанализировал запрос и создал прямо на SQL сервере индексы по полям которые принимают участие в поиске , скорость запроса увеличилась в ТРИ РАЗА!

Beg 22.03.2018 10:10:14
End 22.03.2018 10:12:52

Получаю порядка 2:38 минут , это конечно уже хорошо.

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

Выборка производится из двух смешных по объему таблиц обе порядка 100 тыс записей , другие таблицы не в счет там вообще объемы смешные,
запрос реально кривой, поскольку выполняется несколько минут.

        В другой задаче ( не 1с платформа) имеется порядка 100 миллионов записей , запрос проходит порядка 5 секунд. Правда он состоит из 3 SQL запросов
вместо одного, если соединяю в один - не получаю 5 секунд - получаю несколько минут.

А вот с оптимизацией поиграл.
После того как провел реиндексацию на SQL сервере , по всем индексам , проанализировал запрос и создал прямо на SQL сервере индексы по полям которые принимают участие в поиске , скорость запроса увеличилась в ТРИ РАЗА!

Beg 22.03.2018 10:10:14
End 22.03.2018 10:12:52

Получаю порядка 2:38 минут , это конечно уже хорошо.

Но сам запрос убийственно большой. Программисты пишущие большие запросы наверняка знают - первым запросом надо отсечь максимально большое количество лишних записей которые не нужны для расчета, и только следующем запросе работать с усеченным набором записей, если все лепить в один запрос - скорости падают.
---
Например , допустим имеется таблица операций порядка 100 миллионов записей, поле дата имеет индекс.
нужно сделать некоторые расчеты за день.

Если первым запросом выбрать данные за 1 день , и только в следующем запросе SQL , либо в следующих делать расчет - подав от первого запроса на вход данные, скорость будет в разы выше , чем если все расчеты лепить в одном запросе.
Проверено на практике.
---
действительно много зависит от состояния базы, даже скорость формирования автозаказа является маркером её производительности. Как только просела - значит есть проблема с регламентными заданиями обслуживания базы.

При написании автозаказа (выложено на infostart) запрос оптимизировался декомпозицией на подзадачи с применением временных таблиц. Первоначальный вариант был очень медленным. Как сделали много временных таблиц так подняли производительность в 10 раз.
---
Вот что интересно , где то натыкался что при сдаче экзаменов по 1С , правильным считается "лепить" все в один запрос , именно лепить, другого слова не подбирается.
Считается дурным тоном дробить - на разумные две три выборки.
     Видимо для красоты и солидности втюхивают все в один большой длинный запрос :-)
Если оперировать на пару тыс записей , то разницы конечно нет. Но при росте базы , начнутся проблемы.
---
очень большое количество строк и много-критериальные (большое количество колонок) обрабатываю одним запросом - все очень быстро выполняется (только очень много подзапросов и временных таблиц в запросах), считаю что очень много в производительности зависит от обслуживания базы.
Проблема была серьезная - только вложенные запросы и сложные соединения.
Думаю если проще написать запрос, то будет работать быстро. Да вот пример там текст в модуле https://infostart.ru/public/156873/.
---
Если в базе 700 - 900 миллионов записей скажем это операции за каждый день с приращением в день 50-100 тыс записей,

попробуйте два варианта:

вариант 1) одним большим запросом выбирать всю кучу сразу, при этом в запросе будет тяжелый расчет для одного дня , где надо еще цеплять с десяток - два других таблиц.

вариант 2) первый запрос выбирает во времянку - скажем только один день состоящий скажем из 50 тыс записей в этом запросе выбираем только из одной таблицы по индексированому полю, далее получив времянку , вторым запросом делаем достаточно сложные и тяжелые обработки подцепив пару десятков справочников.

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

Но если вы говорите о основной исторической таблице на 5-10 тыс строк может 100, то разница вероятно будет невелика.
---
yurazyuraz, в 4 порции (захода) создается 50-100 тысяч результатных строк (номенклатура * подразделение).