Re: Proposal: http2 wire format

On 26 March 2018 at 22:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Damir Simunic <damir(dot)simunic(at)wa-research(dot)ch> writes:
> >> On 26 Mar 2018, at 11:06, Vladimir Sitnikov <
> sitnikov(dot)vladimir(at)gmail(dot)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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services