[perrygeo]

There are significant costs to this but maybe some real benefits too. This post certainly doesn't sell the potential benefits well enough.

The big functional gain would be better connection handling. The current process-per-connection model has overhead and it's pretty common to see large database instances with double-digit max connection limits. Because connections are expensive and in (artificially) limited supply, application developers work around the limitations with connection pooling and/or proxy services.

Theoretically, a multi-threaded postgres could easily deal with thousands of concurrent connections - not just a performance improvement but a game changer in terms of application developer UX. When connections are cheap, the application just connects when it needs to communicate, no pgbouncer or connection pools needed.

I have no idea if the multi-threading proposal here is viable, but if it can make connections easier to manage it might be worth it.

[ttfkam]

Connection scalability was greatly improved in v14 and above.

https://www.citusdata.com/blog/2020/10/25/improving-postgres...