4 ms·

> * Having two protocols/data types that two the same thing (text / binary) isn't the end of the world, but it just adds confusion. Also it adds complexity for

> * Having two protocols/data types that two the same thing (text / binary) isn't the end of the world, but it just adds confusion. Also it adds complexity for a different server/proxy/pool implementation. Recommendation: better document binary and add an intent to remove text data types. I don't see us removing the textual transport, unfortunately. The cost of forcing all clients to deal with marshalling into the binary format seems prohibitive to me. What's the server/proxy/pool concern? I don't see a problem there. > Not having an inline cancellation (in same TCP/IP connection) means cancellation isn't supported by many drivers, and even when it is, there are many edge cases were it stops working. Each client implementation has to work around this. Yea, it really isn't great. But it's far from clear how to do it inline in a robust manner. The client just sending the cancellation inline in the normal connection would basically mean the server-side would always have to eagerly read all the pending data from the client (and presumably spill to disk). TCP urgent or such can address that to some degree - but not all that well. > - (C) Named parameters I'm a bit hesitant on that one, depending on what the precise proposal is. Having to textually match query parameters for a prepared statement for each execution isn't great. Overhead should be add per-prepare, not per-execute. If the proposal is that the client specifies, at prepare time, to send named parameters in a certain order at execution time, I'd not have a problem with it (whether useful enough to justify a change in protocol is a different question). > A driver or shim can indeed use text replacement ... b) server computation / allocation cost How come? > - (D) Protocol level language selection. PostgreSQL always starts execution in plain SQL context. If you always execute functions as PL/pgSQL it is just extra overhead. In addition, running ad-hoc PL/pgSQL with named parameters isn't the most easy thing. It is possible, just not easy. This feature plus named parameters so by the time I'm writing my query, I know (a) that I have all my sent parameters available to me bound to names and (b) the first character I type is in the language I want. I can't see this happening. For one, I have a hard time believing that the language dispatch is any sort of meaningful overhead (unless you mean for the human, while interactively typing?). But also, making connections have state where incoming data will be completely differently interpreted is a no-go imo. Makes error handling a lot more complicated, for not a whole lot of benefit.

derefr 7y ago
> Yea, it really isn't great. But it's far from clear how to do it inline in a robust manner. How would you feel about Postgres listening over QUIC instead of/in addition to TCP? It seems to me that having multiple independently-advancing "flows" per socket, would fix both this problem, and enable clients to hold open fewer sockets generally (as they could keep their entire connection pool as connected flows on one QUIC socket.) 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. As a bonus benefit, a QUIC connection could also async-push errors/notices spawned "during" a long-running command (e.g. a COPY) as their own new child-flows, tagged with the parent flow ID they originated from. Same for messages from LISTEN.
- anarazel 7y ago
  > 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

derefr 7y ago

> Yea, it really isn't great. But it's far from clear how to do it inline in a robust manner. How would you feel about Postgres listening over QUIC instead of/in addition to TCP? It seems to me that having multiple independently-advancing "flows" per socket, would fix both this problem, and enable clients to hold open fewer sockets generally (as they could keep their entire connection pool as connected flows on one QUIC socket.) 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. As a bonus benefit, a QUIC connection could also async-push errors/notices spawned "during" a long-running command (e.g. a COPY) as their own new child-flows, tagged with the parent flow ID they originated from. Same for messages from LISTEN.

anarazel 7y ago
> 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