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

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dobes Vandermeer <dobesv(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Date: 2012-03-30 16:11:09
Message-ID: 4F75DB1D.5080403@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

On 03/30/2012 11:41 AM, Robert Haas wrote:
> On Fri, Mar 30, 2012 at 10:55 AM, Dobes Vandermeer<dobesv(at)gmail(dot)com>  wrote:
>> 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.
> I can see that there are some advantages to having an HTTP interface
> to the database, but I think throwing our existing protocol out the
> window or relegating it to the status of a second-class citizen would
> be foolish.


Right, I can't imagine it happening. And I wouldn't really be keen to 
add an alternative protocol either.

I could imagine a client which presented a SPDY interface to the world 
and translated it into standard calls, possibly via libpq.

It's well to remember that we are not a green fields project here.


> HTTP is a non-trivial protocol that tends to impose lots
> of escaping and de-escaping overhead which is unnecessary for people
> who just want to connect to the database and run queries.  I can
> completely understand that someone might want the ability to do GET
> /db/table/pk and have that return an answer very, very quickly, by
> bypassing the usual parser and planner and just firing off an
> index-scan and returning the results as JSON or somesuch.  But I think
> it would be a serious mistake to assume that GET /q?q=myquery is going
> to come out better than what we have now in the general case.


Indeed.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-03-30 16:18:25
Subject: Re: pg_dump incredibly slow dumping a single schema from a large db
Previous:From: Marko KreenDate: 2012-03-30 16:04:59
Subject: Re: Speed dblink using alternate libpq tuple storage

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