Re: Proposal: http2 wire format - Mailing list pgsql-hackers
| From | Craig Ringer |
|---|---|
| Subject | Re: Proposal: http2 wire format |
| Date | |
| Msg-id | CAMsr+YE=qPxHkfU3a4tLW45YvJ6tWY9fk3uSu_CFfTwZNfwyGA@mail.gmail.com Whole thread Raw |
| In response to | Re: Proposal: http2 wire format (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: Proposal: http2 wire format
(Damir Simunic <damir.simunic@wa-research.ch>)
Re: Proposal: http2 wire format (Robert Haas <robertmhaas@gmail.com>) |
| List | pgsql-hackers |
On 26 March 2018 at 22:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Damir Simunic <damir.simunic@wa-research.ch> writes:
>> On 26 Mar 2018, at 11:06, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>>> If anyone finds the idea of Postgres speaking http2 appealing
TBH, this sounds like a proposal to expend a whole lot of work (much of it
outside the core server, and thus not under our control) in order to get
from a state of affairs where there are things we'd like to do but can't
because of protocol compatibility worries, to a different state of affairs
where there are things we'd like to do but can't because of protocol
compatibility worries. Why would forcing our data into a protocol
designed for a completely different purpose, and which we have no control
over, be a step forward? How would that address the fundamental issue of
inertia in multiple chunks of software (ie, client libraries and
applications as well as the server)?
I think the idea is that the protocol (supposedly) solves a lot of the issues we now face, and has sufficient extensibility built in for future use.
I'm not convinced. The v4 protocol TODO hasn't been addressed, not has support for handshake authentication models like SSPI, GSSAPI. There's been no mention of query cancels, text encodings, or any of the other ongoing pain points in the v3 protocol.
I completely understand the desire to support a totally new model where Pg accepts and internally dispatches requests to a separate set of executors, which may or may not be 1:1 with session state. I think we all do. But predicating a protocol change on that being possible is wholly impractical. But it looks like the availability of something like that is just being assumed.
I want to see concrete reasons why this meets our existing and future needs, and those of client apps.
I want to see _EXAMPLES_ of how protocol exchanges would work. Show:
- connect
- authenticate
- establish session
- begin txn
- query
- result set
- query
- error midway through result set
- sync recovery
- rollback
- utility query
- resultset
- query
- query cancel
There's been no visible consideration of overheads and comparison with existing v3 protocol. Personally I'm fine with adding some protocol overhead in bytes terms; low latency links have the bandwidth not to care much compared to payload sizes etc. On high latency links it's all about the round trips, not message sizes. But I want to know what those overheads are, and why they're there.
I'm rapidly losing interest. Unless this goes back toward the concrete and practical I think it's going nowhere.
pgsql-hackers by date: