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

 >> I think it can be done, but only as a temporary solution.
 > My concern about that is that such an inconsistency would make the
 > code complicated, and thus make the maintenance hard.
Agree, but your new patch is quite understandable.

 >> 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?

 >> Also, may be you tell your opinion about an additional optimization 
 >> of Async Append [1]?
 > Is the optimization related to this issue?  (Sorry, I didn’t have time
 > for reviewing the patch in [1] than expected.  I plan to do so next
 > month.)
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.

-- 
regards,
Andrey Lepikhov
Postgres Professional