Re: The case when AsyncAppend exists also in the qual of Async ForeignScan

On Tue, Jul 27, 2021 at 3:22 PM Andrey V. Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
>  >> Maybe we can split async logic into:
>  >> - receiving stage, when we only fetch and store tuples,
>  >> - evaluating stage, when we form resulting tuple and return by a
>  >> scan node.
>  >> I will think about such solution more.

>  > One simple solution along this line I came up with, which is not the
>  > rewrite, is to 1) split process_pending_request() into the two steps,
>  > and 2) postpone the second step until we are called from
>  > postgresForeignAsyncConfigureWait(), like the attached, which I think
>  > would be much consistent with the existing logic.

> Good idea. Are you planning to commit this patch?

Cool!

Here is an updated version of the patch, in which I added/tweaked
comments a bit further.  I'm planning to push this version if there
are no objections from others.

>  >> Also, may be you tell your opinion about an additional optimization
>  >> of Async Append [1]?

>  > Is the optimization related to this issue?

> This optimization tries to postpone choice of async subplans. It allows
> us to make a decision on async capable subplans after all plan
> flattening operations.

Thanks for the explanation!  My understanding is that the optimization
isn’t related to this issue.  Right?

Best regards,
Etsuro Fujita