> How would you feel about Postgres listening over QUIC instead of/in addition to TCP? At some point? Probably not a bad idea. Right now? Doubtful it's worth i

> How would you feel about Postgres listening over QUIC instead of/in addition to TCP? At some point? Probably not a bad idea. Right now? Doubtful it's worth it - the stack doesn't seem ready yet. > and enable clients to hold open fewer sockets generally (as they could keep their entire connection pool as connected flows on one QUIC socket.) I don't think it'd be a meaningful step towards that. We basically have to move to a threaded model to significantly improve the situation. > You'd need to do something fancy to route messages to backends in such a case, but not too fancy—it'd look like a one-deeper hierarchy of fork(2)s, where the forked socket acceptor becomes a mini-postmaster with backens for each of that socket's flows, not just spawning but also proxying messages to them. Not gonna happen. The added context switches would be a very significant increase in overhead. The added processes themselves are but free either. Postmaster not being the immediate parent would complicate the state handling a good bit. EDIT: expand #2