Re: Proposal: http2 wire format

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Damir Simunic <damir(dot)simunic(at)wa-research(dot)ch>
Cc: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: http2 wire format
Date: 2018-03-26 14:56:59
Message-ID: 25633.1522076219@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)?

> This proposal takes the stance that having HTTP2 wire protocol in place will enable wide experimentation with and implementation of many new features and content types, but is not concerned with the specifics of those.

That reads to me as pie in the sky, and uninformed by any engineering
reality. As an example, it's not the protocol's fault that database
server processes are expensive to spin up; changing to a different
protocol will do nothing to make them more lightweight. We've thought
about various ways to amortize that cost, but they tend to fall foul of
the fact that sessions are associated with TCP connections, which we can't
transparently remake or reattach to a different endpoint process. HTTP2
is not going to fix that, because it's still TCP based. I realize that
webservers manage to have pretty lightweight sessions, but that's not a
property of the protocol they use, it's a property of their internal
architectures. We can't get there without a massive rewrite of the PG
server --- one that would be largely independent of any particular way of
representing data on the wire, anyway.

We've certainly got issues that can't be solved without protocol changes.
But starting from the assumption that HTTP2 solves our problems seems to
me to be "Here's a hammer. I'm sure your problem must be a nail, because
all problems are nails".

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-03-26 15:05:26 Re: [HACKERS] MERGE SQL Statement for PG11
Previous Message Pavan Deolasee 2018-03-26 14:39:38 Re: [HACKERS] MERGE SQL Statement for PG11