Уж раз залез - накидаю еще на вентилятор "Ещё в УПП

при переходе на РАУЗ заметили, что на PostgreSQL себестоимость считается в разы медленнее, чем на Microsoft SQL Server. Аналогичная проблема возникает и при расчёте себестоимости в конфигурации ERP.

Например, на пробной базе ERP время расчёта на PostgreSQL 11.5-17.1C (64-bit) на Debian 10 составило по итоговому протоколу 140 минут. На SQL Server тот же расчёт проходит быстрее в 3 раза.
Несколько улучшает время расчёта использование версии PostgreSQL с патчами Сообщение 1858047 »» учитывающими неравномерность распределения значений ключей для nested loop и многоколоночного соединения для hash join. Время расчёта на этой версии уменьшается до 100 минут. Уже лучше. Но ещё не так быстро на SQL Server.

Замер производительности показал, что тормозит выполнение пары запросов, в которых соединяется множество временных таблиц. Общее время выполнения этих двух запросов составило почти час. Текст одного из запросов приведён здесь в файле.

Применение обычной схемы уменьшения времени выполнения запросов для PostgreSQL путём упрощения (вынесения во временные таблицы виртуальных таблиц и сложных подзапросов) не проходит. Упрощать нечего. Запросы и так простые по структуре.

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

Отключение вложенных циклов установкой enable_nestloop = off в файле конфигурации PostgreSQL привело к уменьшению времени расчёта до 50 минут. Но оставлять такую настройку на всё время тоже не есть хорошо - начинаются торможения в других местах. Люди здесь писали про такой опыт.

Выход - отключить nested loop только для тормозящих запросов. Для этого надо как то передать подсказки планировщику PostgreSQL в тексте запроса 1С. Написал расширение для PostgreSQL по мотивам существующего pg_hint_plan. При подключении расширения перед работой планировщика в тексте запроса PostgreSQL ищется магическая строка символов и включаются/выключаются соответствующие опции планировщика. В данном случае, для отключения nested loop на время выполнения текущего запроса достаточно поместить в любое место текста запроса 1С магическую строку "&gH2^7l_q2". Например, можно добавить её в ГДЕ в нейтральном условии "&gH2^7l_q2"<>"111" (которое всегда есть Истина). Таким способом время расчёта себестоимости удалось снизить до 50 минут без плохого влияния на работу ERP в других местах.

Вывод: можно было бы в платформу 1С штатно добавить возможность передачи подсказок планировщику СУБД в тексте запроса. Это не по текущим правилам. Но это позволяет решить проблему, слегка поправив тексты нескольких проблемных запросов. Альтернатива - отказ от использования PostgreSQL."
....
итог:
"От 1С была какая-то реакция? Или всё таки "дело помощи утопающим - дело рук самих утопающих"?

"От 1С не было. С ребятами из Postgres Professional по почте обсудили патч для nested loop с использованием MCV-списков для 12-й версии PostgreSQL."

итог того что я понял, 1с генерит ужас, исправлять не собирается, пг про выпустит патчи чтобы привести в человеческий вид? т.е. 12 будет НЕ ХУЖЕ 11, а даже лучше когда выйдут или вышли патчи. Так?