Can you elaborate on the use case for query multiplexing? Is it so your client would only need to establish one connection with Postgres and then could run as many queries as it wanted?
Can you elaborate on the use case for query multiplexing? Is it so your client would only need to establish one connection with Postgres and then could run as many queries as it wanted?
Microsoft SQL Server has had a similar feature for a while -- Multiple Active Result Sets aka MARS. I don't have a good read on whether it actually helps any workloads. I've seen adapters that don't support it because of the extra complication.
https://learn.microsoft.com/en-us/sql/relational-databases/n...
Multiplexing would have a number of benefits. As you say, each client would only need a single connection regardless of the number of queries being sent. Resulting in:
On the client side, there is usually a local connection pool. When a burst of traffic comes in, the client needs to either wait for the pool to free up or establish a new connection, which adds latency. This latency hit wouldn’t occur with multiplexing.
With multiplexing, systems like pgbouncer would be unnecessary.
Also, even with a thread-per-connection, you can still quickly exhaust the servers resources when you have lots of connections because threads have a lot of overhead. Reducing the number of connections needed would greatly increase the number of clients that a database can serve.
At that point does it make sense to use http/3 to avoid head-of-line blocking on the network?
Not the OP, but yes - just imagine a web server talking to DB over one connection without any connection pooler