Re: HTTP Frontend? (and a brief thought on materialized views) - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: HTTP Frontend? (and a brief thought on materialized views)
Date
Msg-id CAAZKuFbXTc=P7kfknro853agQNraCnmX7HD6ULx8piC4JcP6rg@mail.gmail.com
Whole thread Raw
In response to Re: HTTP Frontend? (and a brief thought on materialized views)  (Daniel Farina <daniel@heroku.com>)
Responses Re: HTTP Frontend? (and a brief thought on materialized views)  (Dobes Vandermeer <dobesv@gmail.com>)
List pgsql-hackers
On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina <daniel@heroku.com> wrote:
D'oh, I munged the order.

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.

> * 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.

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.
>
>
> * 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.


--
fdr


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Next
From: Tom Lane
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)