Re: Proposal: http2 wire format - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: http2 wire format
Date
Msg-id 20180326190150.b7cdltxlrc4ar5b6@alap3.anarazel.de
Whole thread Raw
In response to Re: Proposal: http2 wire format  (Damir Simunic <damir.simunic@wa-research.ch>)
Responses Re: Proposal: http2 wire format  (Damir Simunic <damir.simunic@wa-research.ch>)
List pgsql-hackers
Hi,

On 2018-03-26 20:36:09 +0200, Damir Simunic wrote:
> If so, I’m not suggesting we get rid of FEBE, but leave it as is and complement it with a widely understood and
supportedprotocol, that in fact takes compatibility way more seriously than FEBE. Just leave v3 frozen. Seems like
ultimatebackward compatibility, no? Or am I missing something?
 

Maintaining it forever both in postgres, and in various libraries.


> You likely know every possible use case for Postgres, which makes you
> believe that the status quo is the right way. Or maybe I didn’t flesh
> out my proposal enough for you to give it a chance. Either way, I just
> can’t figure out where would HTTP2 be the same as status quo or a step
> backward compared to FEBE. I can see you’re super-busy and dedicated,
> but if you can find the time to enlighten me beyond just waving the
> “compatibility” and “engineering” banners, I’d appreciate you
> endlessly.

Well, besides vague points you've not elaborated what this is actually
gaining us. From my POV, HTTP2 wouldn't solve any of the interesting
protocol issues since those are one layer above what HTTP2 provides.


> (Oh, it’s my data, too; presently held hostage to the v3 protocol).

What on earth. You can freely migrate off.


> You mention twice loss of control--what exactly is the fear? 

If there's issues with what the library does or how it does it - we
can't fix them ourselves.


> You know what? HTTP2 just might fix it. Getting a new protocol into
> the core will force enough adjustments to the code to open the door
> for the next protocol on the horizon: QUIC, which happens to be UDP
> based, and might just be the ticket. At a minimum it will get
> significantly more people thinking about the possibility of
> reattaching sessions and doing all kinds of other things. Allowing
> multiple protocols is not very different from allowing a multitude of
> pl implementations.

> Help me put HTTP2 in place, and I’ll bet you, within a few months someone will come up with a patch for QUIC. And
thensomeone else will remember your paragraph above and say “hmm, let’s see…"
 

At least I do *NOT* want many protocols in core. We've a hard enough
time to keep up with integrating patches and maintenance to not just
willy nilly integrate multiple new features with unclear lifetimes.

> 
> > 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.
> > 
> 
> A smart outsider might come along, look at an ultra-fast web server,
> then look at Postgres and think, “Hmm, both speak HTTP2, but one is
> blazing fast, the other slow.

Err. What does http2 or the v3 protocol have to do with any of this? The
performance issues v3 has are all above where http2 would be, so ...?


> There are three alternatives to the proposal: do nothing, make a few
> anemic changes to v3, or start a multiyear discussion on the design of
> the next protocol. And you’ll still converge to something like HTTP2
> or QUIC.

*NONE* of the interesting problems are solved by HTTP2. You *still*
need a full blown protocol ontop of it. So no, this doesn't change that.


Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists