Re: RFC: Async query processing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: RFC: Async query processing
Date
Msg-id 9931.1388762412@sss.pgh.pa.us
Whole thread Raw
In response to Re: RFC: Async query processing  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: RFC: Async query processing  (Florian Weimer <fweimer@redhat.com>)
Re: RFC: Async query processing  (Claudio Freire <klaussfreire@gmail.com>)
Re: RFC: Async query processing  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Claudio Freire <klaussfreire@gmail.com> writes:
> On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> Loading data into the database isn't such an uncommon task.  Not everything
>> is OLTP.

> Truly, but a sustained insert stream of 10 Mbps is certainly way
> beyond common non-OLTP loads. This is far more specific than non-OLTP.

I think Florian has a good point there, and the reason is this: what
you are talking about will be of exactly zero use to applications that
want to see the results of one query before launching the next.  Which
eliminates a whole lot of apps.  I suspect that almost the *only*
common use case in which a stream of queries can be launched without
feedback is going to be bulk data loading.  It's not clear at all
that pipelining the PQexec code path is the way to better performance
for that --- why not use COPY, instead?

Or to put it another way, I don't subscribe to "if you build it they
will come" for this proposed feature.  I think that making any use of
it would be so complex and error-prone that the vast majority of apps
won't bother.  Before we start adding a lot of complexity to libpq's
API and internals to support this, you need to make a better case
that there would be a significant number of users.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Changeset Extraction Interfaces
Next
From: Peter Eisentraut
Date:
Subject: Re: ISN extension bug? (with patch)