Re: RFC: Async query processing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RFC: Async query processing
Дата
Msg-id 9931.1388762412@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RFC: Async query processing  (Claudio Freire <klaussfreire@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Changeset Extraction Interfaces
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: ISN extension bug? (with patch)