Skip site navigation (1) Skip section navigation (2)

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

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Dobes Vandermeer <dobesv(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Date: 2012-03-29 19:59:16
Message-ID: CAAZKuFbXTc=P7kfknro853agQNraCnmX7HD6ULx8piC4JcP6rg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina <daniel(at)heroku(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-03-29 20:05:59
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous:From: Daniel FarinaDate: 2012-03-29 19:57:19
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group