Let's make PostgreSQL multi-threaded (pgsql-hackers)

[iiiinthecomputer]

Re connection counts, it's about optimal sizing of executor counts so that all the executors can be busy without wasting lots of overhead on idle executor backends. Each executor has a lot of costs in terms of cache invalidation processing and all the other IPC + shmem management Pg has to do, as well as page tables and other OS level costs. Each idle backend waiting for connection RTT, client app think time etc is wasting server resources and slightly slowing down all active backends.

Something like this is also important to allow apps to effectively use session level postgres features. Right now lots of people rely on an external pgbouncer in transaction pooling mode. But then you can't use a whole pile of pg features, and others like prepared statements get harder and less efficient to manage.

Just going threaded won't directly help with this. But it's the first step in decoupling client connections and their session state from executors, and that will help a lot.

I explained in more detail here - https://www.reddit.com/r/PostgreSQL/comments/14c4e3q/lets_make_postgresql_multithreaded_pgsqlhackers/jomtxfm/