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>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Date: 2012-03-31 13:37:14
Message-ID: CADbG_jawsDdzy=x-fZs+T_Dt_XFPyaRD9Wj1LH=EHDcdxSaCAg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Mar 31, 2012 at 1:44 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:

> On Fri, Mar 30, 2012 at 10:21 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> > Any enhancement here that can't be used with libpq via, say, drop-in
> > .so seems unworkable to me, and that's why any solution that is
> > basically proxying to the database is basically a non-starter outside
> > the very earliest prototyping stages.  The tuple scanning and protocol
> > semantics can and even should remain the same, especially at first.
>
> I should add: proxying could work well if libpq had all the right
> hooks. The server could remain ignorant.  Regardless, upstream changes
> result.
>

Just to be clear, what you are saying that writing a process that accepts
requests by HTTP and translates them into requests using the existing
protocol to send to the server would have unacceptable performance?  Or is
there something else about it that is a non-starter?

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-03-31 14:21:48
Subject: Re: measuring lwlock-related latency spikes
Previous:From: Aidan Van DykDate: 2012-03-31 13:36:07
Subject: Re: Http Frontend implemented using pgsql?

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