Fwiw I agree with Tom lane, there’s a bunch of extension code out there, that would need to be upgraded and verification around multithreaded safety. It’s a pyt

Fwiw I agree with Tom lane, there’s a bunch of extension code out there, that would need to be upgraded and verification around multithreaded safety. It’s a python 2 to 3 transition except assuming correct multi threading in c (most popular lang on extension atm) aka potential disasters for end users. What was missing from the new thread (it’s ref’d in footnotes) is why.. atm the hypothesis is (quoting from linked experiment on multi threading a while back) Direct link which has more discussion, https://www.postgresql.org/message-id/flat/9defcb14-a918-13fe-4b80-a0b02ff85527@postgrespro.ru https://www.postgresql.org/message-id/flat/9defcb14-a918-13f... ‘’’ What are the advantages of using threads instead of processes? 1. No need to use shared memory. So there is no static limit for amount of memory which can be used by Postgres. No need in distributed shared memory and other stuff designed to share memory between backends and bgworkers. 2. Threads significantly simplify implementation of parallel algorithms: interaction and transferring data between threads can be done easily and more efficiently. 3. It is possible to use more efficient/lightweight synchronization primitives. Postgres now mostly relies on its own low level sync.primitives which user-level implementation is using spinlocks and atomics and then fallback to OS semaphores/poll. I am not sure how much gain can we get by replacing this primitives with one optimized for threads. My colleague from Firebird community told me that just replacing processes with threads can obtain 20% increase of performance, but it is just first step and replacing sync. primitive can give much greater advantage. But may be for Postgres with its low level primitives it is not true. 4. Threads are more lightweight entities than processes. Context switch between threads takes less time than between process. And them consume less memory. It is usually possible to spawn more threads than processes. 5. More efficient access to virtual memory. As far as all threads are sharing the same memory space, TLB is used much efficiently in this case. 6. Faster backend startup. Certainly starting backend at each user's request is bad thing in any case. Some kind of connection pooling should be used in any case to provide acceptable performance. But in any case, start of new backend process in postgres causes a lot of page faults which have dramatical impact on performance. And there is no such problem with threads. ‘’’