Тьфу, не на запрос, а на соединение.

Ну да, это старая модель всех классических СУБД, но сейчас почти все уже переделаны на
многопоточность.
Ну и есть ещё нюанс — основной эксплуатант СУБД в качестве операционки сейчас - это Linux, а там что процесс, что поток — очень несущественна разница.

Я всё равно не понял, про что ты, но ответил, может — мимо...

Да я как раз про эту модель. У постгреса архитектура сильно завязана на нее, и отказываться от такой модели, вроде, не планируют.

А Вы знаете, что в большинстве unix-систем (на которые и ориентирован PostgreSQL), процессы и потоки — это практически одно и то же?

> и отказываться от такой модели, вроде, не планируют.

Да, по вышеуказанной причине.

Как так ? Поясните плиз. Это интересно. Ну знаю,что у них pid из одного места берется, но все же странно ,что это одно и тоже практически.

Это не страшно, потому что Линукс.

Например, https://stackoverflow.com/a/809049
Да и вообще, это легко нагуглить.

Ну вот там пишут ,что ipc примитивы сложнее и медленнее.

Вообще, это оффтопик, и лучше идти в Линукс это обсуждать.

Но суть такая , что в Linux многопоточность встроена в систему изначально,
а не налеплена сверху, как в POSIX OS, и поток является там частью ядра.
В Линукс выстроена очень эффективная модель управления памятью,
сильно завязанная на COW, и при этом разница между процессом и потоком стирается
до почти нуля.

Да же комманда ps если я правильно помню в линуксе показывает не процессы, а потоки.

Ну это вот если совсем очень кратко.

Модель коммуникации разная. Тот же процесс , который пишет WAL он через IPC общается с клиентскими процессами , а это медленно.

Это уже в чатики по линуксу идите обсуждать.
Да, может и медленно, но по сравнению с чтением с диска может и пофигу.

Может между процессами и потоками нет разницы существенной с точки зрения ядра, но общение между потоками пишут ,что быстрее . Хороший аргумент про чтение. Значит на какие то части базы это существенно влияет , а на какие то нет.

Это не совсем корректное утверждение.
Треды могут общаться между собой посредством доступа к общему address space. У процессов есть только shared memory, который наверняка накладывает ограничения по возможностям или производительности, а также IPC, который априори менее производителен. Таким образом вывод верен, но основывается он на разных механизмах, а не том что процессы сами по себе почему-то медленее.

А ему всё равно нужна разделяемая память. И это должна быть отдельная (по назначению) задача.
Поэтому разница небольшая, в общем-то.

Всем спасибо за ответы) а есть какой-нибудь телеграм-канал с вакансиями для разработчиков БД?

Этот канал тебя чем не устраивает?

Etki, Вообще, не накладывает.

(после быстрого гуглежа) и то правда

Для конкретной СУБД могут быть свои. Например, https://t.me/pgsqljobs