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

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

From: Dobes Vandermeer <dobesv(at)gmail(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Date: 2012-03-30 14:55:45
Message-ID: CADbG_jbGz8S=PN80DUQMX0L-jTXyJWRYUQ9z53_hBrLkwKmMbg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Mar 30, 2012 at 4:30 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:

> On Thu, Mar 29, 2012 at 10:55 PM, Dobes Vandermeer <dobesv(at)gmail(dot)com>
> wrote:
> >> Virtual hosts. Same port.>> 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.
>

Well, in our case HTTP is a clear win (but not replacement) and SPDY a
potential one (even as a replacement).  Even if SPDY is not widely adopted
it could still replace FEBE if there's a clear advantage to using it, I
don't know enough to make the call right now.

In response to

Responses

pgsql-hackers by date

Next:From: Dobes VandermeerDate: 2012-03-30 15:17:33
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Previous:From: Andrew DunstanDate: 2012-03-30 14:31:54
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)

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