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

On 7/27/21 3:50 PM, Etsuro Fujita wrote:
> On Tue, Jul 27, 2021 at 3:22 PM Andrey V. Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)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.
Thanks. In addition, I will use this patch in TPC-H benchmark tomorrow.
>
>> >> 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?
Right

--
regards,
Andrey Lepikhov
Postgres Professional