On Wed, Mar 31, 2021 at 2:12 PM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: > On Wed, Mar 31, 2021 at 10:11 AM Kyotaro Horiguchi > <horikyota....@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
cleanup-in-async-support.patch
Description: Binary data
