Дичайше подвисает заполнение ТЧ документа по кнопке.
Запустила замер производительности, 87% времени ушло на

ДостЗаказы = Запрос.Выполнить().Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкамСИерархией);

Посмотрела запрос - ничего особого, во вложенный запрос запихнуты соединенные левым соединением 2 документа.
В результате 136 документов и несколько уровней вложенности. Результат запроса - в дереве значений.

Каюсь, лично никогда не использовала эту конструкцию, "ОбходРезультатаЗапроса.ПоГруппировкамСИерархией" и с ДеревомЗначений не работала.
Как-то всегда хватало "Запрос.Выполнить.Выгрузить()" в ТЗ...Но что-то мне подсказывает, что дело как раз в этом.

Подскажите, есть какие-нибудь мысли? А то вдруг это всем известная проблема и "велосипед" ее решения давно изобретен, а я буду тыкаться неделю.... Или я вообще смотрю не в ту сторону, и проблему надо в другом месте искать...

Рекомендую пересмотреть архитектуру данного кода

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

ну и в итогах, выкинуть иерархия, если есть

(0) >Но что-то мне подсказывает, что дело как раз в этом.

Так проверь, выполни с простым обходом и замерь время.
Я все же предположу, что время уходит на выполнение запроса. Если так, то запрос в студию.

(4)
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ВложенныйЗапрос.ПакетныйЗаказ КАК Пакет,
    ВложенныйЗапрос.Контрагент КАК Покупатель,
    ВложенныйЗапрос.КонтрагентПредставление КАК ПокупательПредставление,
    ВложенныйЗапрос.ГрузополучательПредставление КАК ГрузополучательПредставление,
    ВложенныйЗапрос.Грузополучатель КАК Грузополучатель,
    ВложенныйЗапрос.ДоставкаС,
    ВложенныйЗапрос.ДоставкаПо,
    ВложенныйЗапрос.ВесЗаказа КАК Вес,
    ВложенныйЗапрос.СуммаДокумента КАК Сумма,
    ВложенныйЗапрос.Заказ КАК Заказ,
    ВложенныйЗапрос.ГеографическаяПринадлежность КАК ГеографическаяПринадлежность,
    ВложенныйЗапрос.ГеографическаяПринадлежностьПредставление КАК ГеографическаяПринадлежностьПредставление,
    НЕОПРЕДЕЛЕНО КАК Объект,
    НЕОПРЕДЕЛЕНО КАК Регион,
    НЕОПРЕДЕЛЕНО КАК Район,
    НЕОПРЕДЕЛЕНО КАК Город,
    НЕОПРЕДЕЛЕНО КАК НаселенныйПункт,
    ВложенныйЗапрос.АдресДоставки КАК Адрес,
    ВложенныйЗапрос.Заказ.КомментарийДляЭкспедиции КАК Комментарий,
    ВложенныйЗапрос.Грузополучатель.Маршрут КАК Маршрут,
    ВложенныйЗапрос.Заказ.ЗаказРаспечатан КАК ПЧ,
    ВложенныйЗапрос.ВозвратТоваров
ИЗ
    (ВЫБРАТЬ
        ЗаявкаПокупателя.ПакетныйЗаказ КАК ПакетныйЗаказ,
        ЗаявкаПокупателя.Контрагент КАК Контрагент,
        ЗаявкаПокупателя.Контрагент.Представление КАК КонтрагентПредставление,
        ЗаявкаПокупателя.Грузополучатель КАК Грузополучатель,
        ЗаявкаПокупателя.Грузополучатель.Представление КАК ГрузополучательПредставление,
        ЗаявкаПокупателя.ДоставкаС КАК ДоставкаС,
        ЗаявкаПокупателя.ДоставкаПо КАК ДоставкаПо,
        ЗаявкаПокупателя.ВесЗаказа КАК ВесЗаказа,
        ЗаявкаПокупателя.СуммаДокумента КАК СуммаДокумента,
        МаршрутныйЛистЗаказы.Ссылка КАК МЛ,
        ЗаявкаПокупателя.Ссылка КАК Заказ,
        ЗаявкаПокупателя.ГеографическаяПринадлежность КАК ГеографическаяПринадлежность,
        ЗаявкаПокупателя.ГеографическаяПринадлежность.Представление КАК ГеографическаяПринадлежностьПредставление,
        ЗаявкаПокупателя.АдресДоставки КАК АдресДоставки,
        ЗаявкаПокупателя.ВозвратТоваров КАК ВозвратТоваров
    ИЗ
        Документ.ЗаявкаПокупателя КАК ЗаявкаПокупателя
            ЛЕВОЕ СОЕДИНЕНИЕ Документ.МаршрутныйЛист.Заказы КАК МаршрутныйЛистЗаказы
            ПО (МаршрутныйЛистЗаказы.Заказ = ЗаявкаПокупателя.Ссылка)
    ГДЕ
        ЗаявкаПокупателя.ДатаЗаказа = &ДатаЗаказа
        И ЗаявкаПокупателя.Проведен = &Проведен
        И НЕ ЗаявкаПокупателя.Ссылка В (&Список)
        И ЗаявкаПокупателя.ВидДоставки = &Доставка
        И ЗаявкаПокупателя.ПометкаУдаления = ЛОЖЬ) КАК ВложенныйЗапрос
ГДЕ
    (ВложенныйЗапрос.МЛ ЕСТЬ NULL
            ИЛИ ВложенныйЗапрос.МЛ = &Ссылка)

УПОРЯДОЧИТЬ ПО
    ГеографическаяПринадлежностьПредставление,
    ПокупательПредставление,
    ГрузополучательПредставление
ИТОГИ
    СУММА(Вес),
    СУММА(Сумма),
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Заказ)
ПО
    Объект,
    ГеографическаяПринадлежность ИЕРАРХИЯ

(4) в запросе ничего, что может вызывать такое зависание, я не нашла...

(2) спасибо, покопаю в этом направление.
Вообще,  эта конструкция имеет свойство вызывать тормоза, выходит?

Я где-то в коде этой кнопки еще натыкалась на аццкий "Цикл в цикле в цикле", но замер там не останавливается надолго, вроде бы.

(5) Я бы "ВложенныйЗапрос.МЛ = &Ссылка" перенес внутрь, в условия соединения. Ну и к (2) бы прислушался.

(5) ГеографическаяПринадлежность ИЕРАРХИЯ //она точно нужна вам ?? Вам именно группы  справочника вдеть надо  в вашем дереве ?

ну и как бэ, вложенный запрос там не нужен

(8)  хз...я этот запрос вместе с обработкой первый раз в жизни вижу и пока не поняла, насколько оно надо именно в таком виде. Тоже на эту самую "иерархию" обратила внимание, ага.

(1) Таки рекомендую)

(11) данного - это всего, включая запрос, или именно конструкции вывода резульзата, в части
Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкамСИерархией);

?

(12) Да
Просто сделай анализ: Что подаем на вход и что получаем на выходе и зачем так.
зуб даю - можно упростить

(8) черт, до меня дошло, похоже. Это же не СКД. Тут же нет всех этих шикарны настроек вида. Видимо, для того так и сделано...

(14) А в чем сложность сделать на СКД и выгружать в дерево?)

(13) зуб оставьте себе, пригодится)).
Спасибо, посмотрю-проанализирую, идея понятна.

(14) проблема в том, что это не отчет, а данные для последующей загрузки в тч документа. При этом иерархия в ТЧ должна быть сохранена (собственно, в том и была задача изначально)

Типичные причины неоптимальной работы запросов и методы оптимизации:
Использование логического ИЛИ в условиях
Рекомендации
Использование логического ИЛИ в секции ГДЕ запроса
Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.

Например, запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"

следует заменить на запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"

Включение пользователей в несколько ролей, каждая из которых имеет RLS
Если в конфигурации описано несколько ролей с условиями RLS, то не следует назначать одному пользователю более одной такой роли. Если один пользователь будет включен, например, в две роли с RLS - бухгалтер и кадровик, то при выполнении всех его запросов к их условиям будут добавляться условия обоих RLS с использованием логического ИЛИ. Таким образом, даже если в исходном запросе нет условия ИЛИ, оно появится там после добавления условий RLS. Такой запрос так же может выполняться неоптимально - медленно и с избыточными блокировками.

Вместо этого следует создать "смешанную" роль - "бухгалтер-кадровик" и прописать ее RLS таким образом, чтобы избежать использования ИЛИ в условии, а пользователя включить в эту одну роль.

(17) Или плох если разные поля в операндах, в данном случае не в нем дело

Тормозить может RLS ( РАЗРЕШЕННЫЕ )

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

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"

следует заменить на запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"

А вот если бы пример был такой, то она да, актуальна

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Код = "002"

следует заменить на запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Код = "002"

(19) Убери РАЗРЕШЕННЫЕ и проверь тормозит или нет. Дальше видно будет где копать...

(19) Ставлю сотку, что тестирует под полными правами, которые не ограничены РЛС

(21) Разрешенные не влияет на скорость.
Ключевое слово разрешенные чуть чуть изменяет текст исполняемого запроса при наличии ограничения доступа и так же отвечает будет ли ошибка - нет прав или будут только выведены те строки, которые разрешены.
Но для полных прав наличие этого ключевого слова ни на что не влияет

(23) Ну от куда ты знаешь, может ей пользователи пожаловались, а она тупо выдрала запрос из отчёта...

(20) на ИТС так описано

(24) Ну обычно сначала проверяют под полными правами, потом под юзером, и темы уже по другому называются:
У меня летает, а под пользователем тормозит.
ИМХО сам запрос не оптимален

(25) Эта рекомендация устарела, на 1с Эксперт дают совсем другие рекомендации

(27) ИТС, к сожалению, особенно по технологической части, далеко не на 100% актуален.

(26) Кроме того, что выборка двойная, там нет ничего такого неоптимального. Это ГеографическаяПринадлежность ИЕРАРХИЯ всё равно строится на сервере предприятия, а не в базе данных

(29) Там все несколько сложнее

Если памяти мало, а данных много, то

ВЫБРАТЬ

ИЗ

ВЫБРАТЬ


Что в данном случае как бы излишне может существенно сказаться за счёт свопирования

А при чем свопирование, если может быть тупо неоптимальный план?
для того что бы запрос работал медленно, своп не обязателен)
У меня есть хороший пример с РБ, где из таблицы субконто сначала выбираются сотни тыщ записей, а потом фильтруются до нуля строк, потому что так оптимизатор решил.

(19) , (22 )Кстати, использование RLS-то отключено, не  используются RLS в данной базе...А правда, и зачем тогда Разрешенные...

(33) По привычке часто ставят, забей, не в этом ключевом слове дело

(32) А вот именно вложенные запросы и являются часто бедой оптимизатора SQL

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

(35) помнится, внимательно слушала увлекательный спор "совсем 1С-ника" и "скорее СУБД-шника", но оба в данный момент - ведущие прогеры (1С), о том, что оптимальнее: вложенный запрос или временная таблица.
Они чуть не подрались, но к единому мнению так и не пришли)).

(37) есть случаи когда вложенные запросы лучше.
Есть когда временные таблицы.
Разница в том, что временные таблицы особенно большие - не бесплатны для СУБД и могут быть достаточно дорогой операцией, а вложенные запросы - для оптимизатора черный ящик

(38) что-то мне подсказывает, что в данном запросе вообще пофиг, ВТ или вложенный...

(39) А ты перепиши и так и так и проверь

(32) Если памяти нет, а тут данные почти * 2 ( если где не шибко поможет ), то может быть так же проблемой. Хотя ЗаявкаПокупателя.ДатаЗаказа = &ДатаЗаказа явно ограниченный набор, а вот И НЕ ЗаявкаПокупателя.Ссылка В (&Список) список может быть очень большим

ГДЕ
        ЗаявкаПокупателя.ДатаЗаказа = &ДатаЗаказа
        И ЗаявкаПокупателя.Проведен = &Проведен
        И НЕ ЗаявкаПокупателя.Ссылка В (&Список)
        И ЗаявкаПокупателя.ВидДоставки = &Доставка
        И ЗаявкаПокупателя.ПометкаУдаления = ЛОЖЬ

(38) в целом рекомендация вендора такая:
Временная таблица лучше чем вложенный запрос.
Отсутствие временной таблицы лучше, чем ее наличие.
Но если есть проблема, и вложенный запрос показывает лучшее время - то оставить его будет разумно.
(39) так это или нет - может и стоит проверить, просто глянь сколько по времени выполняется вложенный запрос и сколько строк он возвращает.

(42) в целом, имхо, лично я ВТ больше люблю - как-то он читабельнее и удобнее.
Попробую переделать чисто ради любопытства, но в том, что дело в этом, крайне сомневаюсь...

Тут можно несколько улучшить это, если маршрутных листов много, а индекса нет:

ЛЕВОЕ СОЕДИНЕНИЕ Документ.МаршрутныйЛист.Заказы КАК МаршрутныйЛистЗаказы
            ПО (МаршрутныйЛистЗаказы.Заказ = ЗаявкаПокупателя.Ссылка)

сделать так, может чего и выйдет :)

ЛЕВОЕ СОЕДИНЕНИЕ Документ.МаршрутныйЛист КАК МаршрутныйЛист
            ПО МаршрутныйЛист.Дата >= ЗаявкаПокупателя.Дата)

СОЕДИНЕНИЕ Документ.МаршрутныйЛист.Заказы КАК МаршрутныйЛистЗаказы
         ПО МаршрутныйЛистЗаказы.Ссылка = МаршрутныйЛист.Ссылка
          И МаршрутныйЛистЗаказы.Заказ = ЗаявкаПокупателя.Ссылка

(41) с памятью у меня все норм (4 гига) - но тоже тупит по-страшному. У пользователей с памятью плохо (гиг может быть, компы древние), так у них вообще...

(45) Запросы выполняются на сервере, или это файловая база?

(46) на сервере

(47) 4 гб на сервере?

(44) Хотя сомнительно, если отчёт будет строить сильно задним числом. Лучше индекс влепить по колонке Заказ в Документ.МаршрутныйЛист.Заказы

(48) я про свой комп конечно, что-то я ответила, а потом уже подумала, что какая разница-то, надо на сервере память смотреть.
На сервере не знаю, в понедельник спрошу у админов.

(49) спс, попробую теперь все эти рекомендации осмыслить и применить...

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

(51) База растет и постепенно такие вещи будут проявляться

(51) Попробуй индексы перестроить. Если MS SQL сделай регламент, что бы индексы пересоздавать и статистику пересобирать

(16) сколько позиций в &Список?

(53) а шо это даст?
При подзапросах оптимизатор может ошибиться в выборе плана запроса
(49) Лишь бы индексы налепить..,, будет у тебя индекс и...? Думаешь соединяться будет быстрее - увы)
Как сказали в (52): больше данных, больше тормозов в данном случае.

(21) )) посмотрел бы я как оно станет понятно куда копать.
Или rls или нет, если нет, то копать до утра? - так?)

(2) ,(3), (4)
Пропробовала с разными типами группировок и вообще без них в Выгрузить(), убрала иерархии в запросе, попробовала комбинации всех вариантов - разница есть, но она минимальна.
Быстрее всего, на удивление, отрабатывает вариант "Убрать иерархию из запроса, но при этом оставить ОбходРезультатаЗапроса.ПоГруппировкамСИерархией".

Время исполнения с момента нажатия кнопки "заполнить" до окончания выгрузки результата запроса (замером производительности)  - 25,142438 , 99. 72 %.
Изначальный вариант - 25, 578 640, 99.8%

(40) при замене вложенного запроса на ВТ результат еще хуже - 26,125940, 99.79%
(48) на сервере суммарно 32 гб, из них 29 отданы под SQL и почти все заняты.

Остальное пока не проверила.

Смущает то, что кон работал на ура долгое время, а потом внезапно начались дикие висяки, мешающие работать
Мне кажется, или при естественном раздувание базы уменьшение скорости происходило бы равномерно?

Сейчас запустила ТИИ (сдуру, похоже это надолго) - вдруг полегчает...

профайлер SQL, ТЖ 1С надо смотреть, раз дело в иерархии.

(58) эмм...а можно перевести? что значит "профайлер SQL, ТЖ 1С"?

(58) https://docs.microsoft.com/ru-RU/sql/tools/sql-server-profiler/sql-server-profiler?view=sql-server-2017   оно?

(58) а ТЖ - технологический журнал, наверное)))?

(5) Поставь "индексировать" для ЗаявкаПокупателя.ДатаЗаказа.
И озвучь кол-во документов ЗаявкаПокупателя в базе.

(60), (61) так точно

(62) насчет (58) я поняла уже, пропустила этот момент и сразу не посмотрела. Сейчас, еще одну копию сделаю, и проверю эти моменты, а то прежняя копия подвешена намертво ТИИ.

(54) В &Список от 0 (чаще всего 0, в 99% случаев), до нескольких (2-5-10) позиций, в общем ни о чем.

(62) заявок в базе много, но в &Список попадает после отбора от 0 до нескольких штук.
Грубо говоря попадает туда что-то в том случае, если случайно они не были добавлены раньше.

Кстати, в консоли запрос отрабатывает моментально.
Висяки начались вскоре после обновления платформы, до этого алгоритм успешно работал не один год.
Платформа 1С:Предприятие 8.3 (8.3.13.1644)

(0) Вы не справитесь.
Забудьте и пишите код дальше.

(68) вы так оптимистичны!
А надо). Пока не справлюсь, код писать не дадут :)

(69) посмотрите план запроса в SQL и покажите его здесь. даже погуглил за вас.
https://catalog.mista.ru/public/940250/

Удивительно, но факт: на тестовой базе проблему решило полное ТИИ.

Время выполнение запроса до ТИИ:
25,233779    99,69 %
Время выполнения запроса после ТИИ:
0,212256    87,23%

скорее всего помог пересчет итогов, но это неточно.

(72)
В процессе ТИИ была "критическая ошибка";
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Cannot insert the value NULL into column '_Fld835', table 'copy4.dbo._Reference73NG'; column does not allow nulls. INSERT fails.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1

_Reference73NG - это Справочник.СопроводительныеДокументы .

Не уверена, что "собака там зарыта", но других именно ошибок не было, только общие уведомления.
Осталось то же самое сделать на рабочей базе.

Кстати, не знаете, можно ли как-то узнать чистое время выполнения ТИИ? А то я что-то проглупила и не засекла.