Re: Asynchronous Append on postgres_fdw nodes.
От | Etsuro Fujita |
---|---|
Тема | Re: Asynchronous Append on postgres_fdw nodes. |
Дата | |
Msg-id | CAPmGK1637W30Wx3MnrReewhafn6F_0J76mrJGoFXFnpPq4QfvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Asynchronous Append on postgres_fdw nodes. (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: Asynchronous Append on postgres_fdw nodes.
|
Список | pgsql-hackers |
On Wed, Mar 31, 2021 at 2:12 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Wed, Mar 31, 2021 at 10:11 AM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: > > + * We'll prefer to consider this join async-capable if any table from > > + * either side of the join is considered async-capable. > > + */ > > + fpinfo->async_capable = fpinfo_o->async_capable || > > + fpinfo_i->async_capable; > > > > We need to explain this behavior in the documentation. > > It looks somewhat inconsistent to be inhibitive for the default value > > of "async_capable", but agressive in merging? > > If the foreign table has async_capable=true, it actually means that > there are resources (CPU, IO, network, etc.) to scan the foreign table > concurrently. And if any table from either side of the join has such > resources, then they could also be used for the join. So I don't > think this behavior is aggressive. I think it would be better to add > more comments, though. > > I'll return to this after committing the patch. I updated the above comment so that it explains the reason. Please find attached a patch. I did some cleanup as well: * Simplified code in ExecAppendAsyncEventWait() a little bit to avoid duplicating the same nevents calculation, and updated comments there. * Added an assertion to ExecAppendAsyncRequest(). * Updated comments for fetch_more_data_begin(). Best regards, Etsuro Fujita
Вложения
В списке pgsql-hackers по дате отправления: