Re: HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 10:55 PM, Dobes Vandermeer <dobesv(at)gmail(dot)com> wrote:
>> Virtual hosts. Same port.
>
> In that case, the frontend would not be tied to a specific PostgreSQL
> server, then?  I think initially this might complicate things a bit, and you
> could solve it by putting an HTTP proxy in front to do the virtual hosts for
> you.

I think these problems are treatable, as you mention, and if there is
to be any value at all by using mostly off-the-shelf components
(which, at this time, are rarer for the new-generation stuff). That's
the draw, for me.

> Ah, I get it - you want a way to add some extra information to the protocol
> in a backwards compatible way.  HTTP (and SPDY) provides a "standard" way to
> do that.  Makes sense.
>
> I'll make a note of these and hash out the details a bit more once there's
> something working to add them to.

A lot of them are old ideas, but it would be nice to encourage
experimentation by getting over some of the
small-matter-of-programming and backwards-compatibility issues.

>> I think SPDY or like-protocols [...] give a crisp treatment to
>> interactive, stateful workloads involving
>>
>> back-and-forth between client and server with multiplexing, fixing
>> some problems with the hacks in HTTP-land from before.
>
> It sounds like at some level you're really talking about replacing the
> built-in protocol with SPDY because SPDY is possibly a better baseline than
> updating the existing protocol.  That's an interesting idea, I think this
> project could evolve in that direction if there's demand for it.

If only so there is a smaller set of arbitrary decisions to make about
how to delimit messages...but if SPDY doesn't get widely deployed, or
exacts an unacceptable performance penalty, it is game over. The
worst possible outcome is the thing that becomes common also is
impractical for session-oriented sequential SQL execution, but I am
hopeful that given the use cases driving this standardization process
that this is less likely to happen. FEBE's framing/message format
doesn't seem like an area where people are itching to try wild and
crazy changes unique to Postgres (maybe someone has...) so using a
more commonly seen delimitation format seems like a concession that
opens a lot of more useful interesting doors.

This discussion is somewhat premature because HTTP 2.0 isn't
standardized, nor has SPDY become a wide-spread defacto format
(although the percentage of well-known web-infrastructure projects
implementing it has grown both impressively both recently and
overall), and there are not even straw-man bandwidth/latency
measurements (in terms of vs. FEBE), but as long as someone is
bringing up HTTP, I thought it worth discussing in a little more
depth, because it's something I poll regularly mentally, looking for a
sign that It's Time. It wasn't ready enough for me to start a thread,
but clearly I couldn't quite resist replying to one...

--
fdr