Re: Asynchronous Append on postgres_fdw nodes.

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Asynchronous Append on postgres_fdw nodes.
Дата
Msg-id CAPmGK17yjZg2ajhs3erpfOKj+sg6yZU_gwvaeOV+j8g2E2bdcA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Asynchronous Append on postgres_fdw nodes.  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Ответы Re: Asynchronous Append on postgres_fdw nodes.  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Список pgsql-hackers
On Tue, Apr 27, 2021 at 9:31 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Mon, Apr 26, 2021 at 7:35 PM Andrey V. Lepikhov
> <a.lepikhov@postgrespro.ru> wrote:
> > Small mistake i found. If no tuple was received from a foreign
> > partition, explain shows that we never executed node.

> > The patch in the attachment fixes this.
>
> Will look into this.

The patch fixes the issue, but I don’t think it’s the right way to go,
because it requires an extra ExecProcNode() call, which wouldn’t be
efficient.  Also, the patch wouldn’t address another issue I noticed
in EXPLAIN ANALYZE for async-capable nodes that the command wouldn’t
measure the time spent in such nodes accurately.  For the case of
async-capable node using postgres_fdw, it only measures the time spent
in ExecProcNode() in ExecAsyncRequest()/ExecAsyncNotify(), missing the
time spent in other things such as creating a cursor in
ExecAsyncRequest().  :-(.  To address both issues, I’d like to propose
the attached, in which I added instrumentation support to
ExecAsyncRequest()/ExecAsyncConfigureWait()/ExecAsyncNotify().  I
think this would not only address the reported issue more efficiently,
but allow to collect timing for async-capable nodes more accurately.

Best regards,
Etsuro Fujita

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: decoupling table and index vacuum
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Dubious assertion in RegisterDynamicBackgroundWorker