Прилетела задача - тормозит операция изменения Доступности видов рабочих центров через АРМ. На MSSQL Server операция завершается через минуту, а на PostgreSQL - около часа. Копия базы предоставлена - можно начинать копать. Так как проблема чётко описана и легко воспроизводится решил не мудрить и использовать обычный замер производительности через конфигуратор. Подключать на этом этапе ТЖ не вижу смысла.
Не забываем важный нюанс - чтобы замер производительности отработал, сервер 1С должен быть запущен с ключом-debug.
Запускаем базу, замер производительности и повторяем действия, которые приводят к зависанию. Самое долгое на этом этапе - подождать час, чтобы получить результаты замера.
Кстати, тут произошёл fail - я заранее не уточнил, включен ли -debug на сервере или нет. А оказалось, что нет. Пришлось включать и повторять замер. Не будьте, как я...
По замеру сразу видно виновника - какой-то запрос в общем модуле ХБК_ПривилегированныйМодуль. Запрос этот вызывается из функции ХБК_СУПДПриЗаписи, которая подключена к подписке на события и вызывается ПриЗаписи любых документов. И в этой функции есть такой запрос
Подозреваемого видно сразу - это неявное левое соединение (обращение через точку к реквизиту ПометкаУдаления) для полей ДокументОснование и ПодчинённыйДокумент. Но почему такие тормоза? Для этого необходимо понять, какой тип имеют упомянутые выше поля.
Попались голубчики. Тип ДокументСсылка, а значит неявное левое соединение со всеми документами. А их в ERP ой как много. Для чистоты эксперимента смотрим на запрос через auto_explane (как это настраивается и как с этим работать, можно посмотреть в статье коллеги Владимира Крючкова Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками). Наш махонький запрос превратился в запрос на 2 400+ строк. Вот это да.
Дальше всё просто. Оптимизируем запрос, убирая обращение через точку, н-р: получая пометку удаления из переданной сюда ссылки и передав её в запрос как параметр.
Заключение
Коллегам из компании Омега спасибо, что разрешили поделиться материалом. Написать статью решился исходя из двух соображений:
1. Показать, что PostgreSQL более требователен к качеству написанных запросов, чем SQL. Напоминаю, что на SQL этот же код отрабатывает за минуту.
2. Напомнить, что неявные соединения с полями составного типа - это зло. Будьте бдительны.
Спасибо за прочтение. С уважением, Вдовенко Сергей.
