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

On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:

> On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina <daniel(at)heroku(dot)com>
> wrote:

More technical concerns:
> > * Protocol compression -- but a bit of sand in the gears is *which*
> > compression -- for database workloads, the performance of zlib can be
> > a meaningful bottleneck.
>

I think if performance is the issue, people should use the native protocol.
This HTTP thing should be more of a RAD / prototyping thing, I think. So
people can be in their comfort zone when talking to the server.

> * Something similar to the HTTP "Host" header, so that one can route
> > to databases without having to conflate database identity with the
> > actual port being connected to. Yes, theoretically it can be done
> > with weird startup packet gyrations, but that is firmly in the "weird"
> > category.
>

Isn't the URL good enough (/databases/<dbname>) or are you talking about
having some some of "virtual host" setup where you have multiple sets of
databases available on the same port?

Socialish (but no less important):
>
> > * A standard frame extension format. For example, last I checked
> > Postgres-XC, it required snapshot information to be passed, and it'd
> > be nice that instead of having to hack the protocol that they could
> > attach an X-Snapshot-Info header, or whatever. This could also be a
> > nice way to pass out-of-band hint information of all sorts.
>

I am sorry to admit I don't understand the terms "frame extension format"
or "Postgres-XC" in this paragraph ... help?

> > * HTTP -- and *probably* its hypothetical progeny -- are more common
> > than FEBE packets, and a lot of incidental complexity of writing
> > routers is reduced by the commonality of routing HTTP traffic.
>

This is an interesting comment. I'm not sure how to test whether an HTTP
based protocol will be better supported than a proprietary one, but I think
we have enough other reasons that we can move forward. Well we have the
reason that there's some kind of love affair with HTTP based protocols
going on out there ... might as well ride the wave while it's still rising
(I hope).

As for SPDY I can see how it may be helpful but as it is basically a
different way to send HTTP requests (from what I understand) the migration
to SPDY is mainly a matter of adding support for it to whatever HTTP
library is used.

Anyone have a thought on whether, for the HTTP server itself, it should be
integrated right into the PostgreSQL server itself? Or would it be better
to have a separate process that proxies requests to PostgreSQL using the
existing protocol? Is there an API that can be used in both cases
semi-transparently (i.e. the functions have the same name when linked right
in, or when calling via a socket)?

Cheers,

Dobes