Записки оптимизатора 1С (ч.12). СрезПоследних в 1C: Предприятие на PostgreSQL. Почему же так долго?

[alan008]

По хорошему надо бы в MS SQL параметр max_dop (max degree of parallelism) выставить в 1 и посмотреть план без параллелизма, он должен быть более понятный и логичный. Параллельные планы иногда тормозят, когда база на hdd, а не на ssd

[gallam]

Торможение на параллелизме напрямую никак не связанно с производительностью дисков.

[koloskovv]

Если вы про синтетический тест, то использовался ssd диск. Запрос выполняется мгновенно, к параллелизму претензий нет )).

[kale]

А что мешает самой 1С формировать оптимальный текст запроса, в зависимости от используемой СУБД?

[koloskovv]

Ну это риторический вопрос.

Поэтому пока вендоры размышляют мы нашли альтернативный вариант.

[ruomserg]

Но это же сумасшествие! Тул в середине меняет запрос! А как потом разбираться если оно бахнет что-то не то в таблице?! ИМХО - это слишком опасный паттерн, особенно основанный на регулярках!

[koloskovv]

Я вас понимаю - без должного инструментария не очень понятно и даже боязно идти в эту историю. Но мы там уже более 10 лет. Покажу примерный ход внедрения QProcessing (QP).

1. Мы всегда внедряем QProcessing в связке с мониторингом Perfexpert (PE), который позволяет собирать трассы разных тяжелых запросов, а также трассу ВСЕХ запросов, которые были модифицированы QP'ом. Поэтому всегда можно посмотреть и проверить результат. Без PE никак. Даже если вам не нужен мониторинг, на период внедрения, он у вас будет установлен.

2. Интерфейс QP позволяет прогнать вручную запросы через правило, убедиться, что они модифицируются правильно или не модифицируются вообще. Дальше модифицированные запросы нужно просто выполнить в Studio на тесте и убедиться, что результат запроса один и тот же, а время сократилось. Да, тестовый стенд также необходим, как и мониторинг.

3. Только после многократного прогона можно переходить в продуктив.

4. Еще важно! Если вдруг запрос после модификации стал выполняться на проде с ошибкой (exception, например, из-за синтаксиса), то QP повторно отправляет на SQL Server запрос, но в исходном виде. То есть, пользователь ничего не заметит, кроме того, что запрос будет выполняться опять долго. Ну а разработчики/администраторы в логах QP быстро увидят эту ситуацию.

Как-то так.

[HADGEHOGs]

Что юристы Софтпоинта скажут про целостность лицензионного соглашения 1С с этим инструментом, меняющим внутренние запросым1С?

[AQIS]

Там вот у 1С ещё приписка есть...

Данное ограничение необходимо для обеспечения стабильности работы механизмов системы, осуществления поддержки и возможности перехода на новые версии «1С:Предприятия».

Если выполняется данное условие, то какие проблемы?

[AQIS]

.

[anshdo]

Но ведь 1С и так уже использует собственный патч к PgSQL для повышения производительности. Не лучше ли подкрутить исходники этого патча? Он же опенсорсный.

[Tippy-Tip]

Программисты платформы "ниасилили" особенностей СУБД, которые работают в режиме версионирования записей. Вместо этого они выпустили патч, который превращает ванильный PostgreSQL в подобие "блокировочника" а-ля MS SQL (чтобы накладывать блокировки не на уровне записей, а на уровне таблиц), потому что с ванильным PostgreSQL 1С не работает от слова "совсем". Хотя спонсирование российских команд разработчиков PostgreSQL позволило протолкнуть некоторые решения этого патча в основную ветку (то ли с 13, то ли с 14 версии).

Но суть статьи не в этом (не в патче). Суть в том, что это сама платформа 1с генерирует "кривые" запросы при использовании PostgreSQL И никакими патчами к СУБД это не исправить. Тут или падишах умрет, или ишак: или текущая команда таки выучит PL/pgSQL, или их поменяют на тех, кто знает этот диалект.