From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dobes Vandermeer <dobesv(at)gmail(dot)com> |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, 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 15:41:03 |
Message-ID: | CA+TgmoZ7GiMgGSb0PfDyN3fosh2u0_8xD8X7JwQO624Nr7RAag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Roest | 2012-03-30 15:51:58 | pg_dump incredibly slow dumping a single schema from a large db |
Previous Message | Dimitri Fontaine | 2012-03-30 15:19:23 | Re: Command Triggers patch v18 |