Погуглил, ответы то есть, но читая их окончательно запутался :) Ранее с PostgreSQL никогда не работал я.

Есть 1с + PostgreSQL и нормальный многоядерный проц на сервере. При некоторых операциях (например, закрытие месяца в БП) создаётся огромный запрос, при выполнении которого PostgreSQL жрёт только одно ядро CPU на сервере. Как я понял (могу ошибаться) PostgreSQL может жрать 2 ядра если выполняет 2 запроса одновременно. Но PostgreSQL не может как бы "разбить" один большой запрос и выполнять его на двух ядрах или более.

А вот Microsoft SQL якобы так может и делает это.

Вообще на сервере 16 ядер. Контора переехала недавно с Microsoft SQL на PostgreSQL, после чего со слов пользователей 1с стало "дико тормозной". Попытки оптимизировать PostgreSQL принимал местный админ, не помогло. Теперь хотят переехать обратно на Windows и Microsoft SQL.

Вот главный вопрос в котором я запутался: действительно ли Microsoft SQL разбивает один запрос так, что выполняет его на нескольких ядрах параллельно, а PostgreSQL так не умеет? Именно один запрос, а не несколько.

Просто если это верно, тогда однозначно надо переезжать на Microsoft SQL.

Заранее отвечу какого хрена тогда они переехали: как я понял хотели сэкономить на лицензии.

(0) У нас был случай, заказчик "настроил" сервак в 2 раза медленнее чем из "коробки", даже на хабре по высокопроизводительные сервера писал статейки и как настраивать ;-))))

(0) "действительно ли Microsoft SQL разбивает один запрос так, что выполняет его на нескольких ядрах параллельно, а PostgreSQL так не умеет"
Да, разбиваает. Но это не рекомендуют включать для 1с, потому что при этом возможны взаимоблокировки и вылеты приложения по таймауту.

"переехала недавно с Microsoft SQL на PostgreSQL, после чего со слов пользователей 1с стало "дико тормозной""
Это известное проклятие постгреса под названием "nested loop join", которое особенно сильно проявляется именно в 1с, поскольку там можно легко и просто соединить две подзапроса, даже не понимая этого, а постгрес рассуждает так "я не знаю статистику соединяемых таблиц, значит они маленькие и их надо соединять вложенными циклами". В типовых в основном это пооптимизировали, но возможно что не везде.

А чтобы постгрес не жрал проц, есть простой способ, прописать "enable_nestloop=off", тогда он будет больше жрать диск и временные таблицы)

(2) Спасибо

(0) Postgres умеет параллельно выполнять запросы.
вот вам документация:
https://postgrespro.ru/docs/postgresql/15/parallel-query

ну и вообще в ютубе есть замечательные курсы по postgres от компании postgresPro БЕСПЛАТНЫЕ. Посмотрите хотя-бы их перед тем, как внедрять слонов

(5) Возможно вы не поняли мой вопрос. Мой вопрос в том может ли PostgreSQL распарралелить выполнение именно одного-единственного запроса (большого), а не несколько запросов. Как я понял из статей: PostgreSQL так не умеет, а Microsoft SQL так умеет. Я не уверен что верно понимаю.

(7) enable_nestloop=off для начала попробуйте, может этого хватит вам

(7) пишется "распараллелить"

(9) ок, учту

(8) Спасибо. Уже попробовали - не помогло. Пробовал не я, а местный админ, он в этом больше понимает. Говорит не помогло вообще. Но попробовать явно стоило, тоже натыкался на такую рекомендацию когда гуглил.

(0) В общем случае мы рекомендуем устанавливать значение параметра max degree of parallelism равным 1, то есть запрещать Database Engine параллельное выполнение запросов.
https://its.1c.ru/db/metod8dev/content/5945/hdoc

Вот же https://habr.com/ru/companies/slurm/articles/446706/
Настройте конфиг, что бы он только очень тяжелые запросы параллелил.

(12) Это в общем случае. Что в MS SQL, что в Postgre есть параметр отвечающий за стоимости операции распараллеливания. Параметр сложный в настройке, но если с ним поиграться, то можно получить плюсы от распараллеливания. Причем серьезные.

(14)Интересно, спасибо. Обычно не заморачивались и следовали рекомендации, но интересно будет покопать в эту сторону. Может видели какие-то статьи на эту тему?

>переехала недавно с Microsoft SQL на PostgreSQL, после чего со слов пользователей 1с стало "дико тормозной".

имхо настройки PGSQL кривые

причем дело не в параллелизме скорее всего

В PostgreSQL 10 параллельная обработка включена по умолчанию

(15) Общих рекомендаций по данному параметру быть не может, т.к. его настройка сильно зависит от природы нагрузки на базу и архитектуру базы.
Для себя нашел такой вариант (не уверен что оптимальный).
На копии базы отключаю параллелизм. Прогоняю ТиИ базы с контролем времени.
Включаю параллелизм.  Прогоняю ТиИ базы с контролем времени.
Поскольку ТиИ очень хорошо распараллеливается, то время будет разным.
Дальше включаю распараллеливание и ставлю низкую стоимость распараллеливания. Опять ТиИ с замером времени. Последовательно повторяю ТиИ с некоторым увеличением стоимости распараллеливания. Как только время проведения ТиИ заметно увеличивается, уменьшаю стоимость на предыдущее значение. Обычно подобная настройка дает прирост производительности при работе подсистемы бюджетирования в УПП и в ERP.
Получается что на простых запросах система не включает распараллеливание, а на сложных включает.