нашел такое обсуждение, самое вкусное в коментариях
https://infostart.ru/1c/articles/1031400/

уж раз залез - накидаю еще на вентилятор
"Ещё в УПП при переходе на РАУЗ заметили, что на 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."

давайте обратимся к прописям.
https://postgrespro.ru/docs/postgresql/12/explicit-joins

Чтобы планировщик соблюдал порядок внутреннего соединения, выраженный явно предложениями JOIN, нужно присвоить параметру выполнения join_collapse_limit значение 1. (Другие допустимые значения обсуждаются ниже.)

Чтобы сократить время поиска, необязательно полностью ограничивать порядок соединений, в JOIN можно соединять элементы как в обычном списке FROM. Например, рассмотрите следующий запрос:

SELECT * FROM a CROSS JOIN b, c, d, e WHERE ...;

Если join_collapse_limit = 1, планировщик будет вынужден соединить A с B раньше, чем результат с другими таблицами, но в дальнейшем выборе вариантов он не ограничен. В данном примере число возможных вариантов соединения уменьшается в 5 раз.

Упрощать для планировщика задачу перебора вариантов таким способом — это полезный приём, помогающий не только выбрать сократить время планирования, но и подтолкнуть планировщик к хорошему плану. Если планировщик по умолчанию выбирает неудачный порядок соединения, вы можете заставить его выбрать лучший, применив синтаксис JOIN, конечно если вы сами его знаете. Эффект подобной оптимизации рекомендуется подтверждать экспериментально.

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

там как раз все явно разбито на кучу временных таблиц

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

оптимизатор ПГ сложный запрос с соединением многих временных таблиц выбирает неоптимальный план запроса.
МС его проглатывает лучше.

решение - товарищ написал патч для ПГ скл, который при наличии неких символов в запросе отключал для них nested loop.

с ПГ про обсудили что в 12 ПГ внесут некий патч.

ИТОГ
1) Оптимизатор ПГ 11 на данном сложном запросе оказался хуже МС
2) товарищ починил костылем,  к его пожеланию переделать костыль на рычаг который можно штатно использовать через 1С - 1С осталась глуха.
3) ПГ про обещали что то сделать в ПГ 12

да в данной задаче ПГ 12 должно быть не хуже.

Господа, а подскажите пожалуйста, как то можно у всех пользователей в 1с заменить имя принт-сервера не подходя к каждому пользователю ? Допустим было \\app1\$pint_name а стало \\app2\$print_name ? Принт сервера идентичные, сделать CNAME на \\app1 нельзя. Можно как то эти настройки найти в конфигураторе либо в БД ? Спасибо

Добрый день. Подскажите что надо системе..обновил 1с на сервере. Статус сервиса выдал такую ошибку. Вернул старую версию - такая же история (((

либы нет

или точнее поломана

На сервере где ошибок нет тоже папки security нет. Или она в другой папке?

Насколько критично?

так-то ничего хорошего

а systemd стоит?

Такого сервиса нет

systemctl status srv1cv8 что говорит?

или давай от обратного какая ось, версия