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

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Dobes Vandermeer <dobesv(at)gmail(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-04-02 07:46:01
Message-ID: CAAZKuFaQ0EgZFgDbf1_dHwCO8bvrzMTyxs_qFntojerRy1x8pA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 31, 2012 at 6:37 AM, Dobes Vandermeer <dobesv(at)gmail(dot)com> wrote:
> 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?

I don't think it's so much an unworkable performance regression as
getting people to seriously try experimenting with useful extensions
to FEBE, and so that real applications (and their maintainers) can
justify a little time to test and experience (for good or for ill)
those enhancements in a production or at least staging setting and
giving them a fair shake.

As a reminder, this is based on a conjecture that there is a large
dimension of useful experimentation that involves simply interlacing
information between FEBE messages, and then intercepting and
processing those on both server and client, and that these message can
be composed in many situations (i.e. multiple extensions can work
well).

For me, HTTP2 figures into all of this because it may be one way to
paint some aspects of the protocol-extension bikeshed with the same
color more people might use, and as long as that color is basically
functional we can seek to understand if a standard bikeshed-color
allows us to take advantage of anticipated large, low-cost reserves of
paint. Consider this analogy stretched.

--
fdr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-04-02 09:16:21 Re: Event scheduling
Previous Message Simon Riggs 2012-04-02 07:36:14 Re: Event scheduling