Subject: Re: The case when AsyncAppend exists also in the qual of Async
 ForeignScan
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
References: <fe5eaa19-1704-e4a4-76ee-3b9d37ade399@postgrespro.ru>
 <CAPmGK170Y-6ysT1Vk+dmz4wXBq6Zq4+Sw2kMywsTdXduA0Svyw@mail.gmail.com>
Reply-To: CAPmGK15eY_P5AEC6-HjZusx2euftT0KD94ywaeJ=f3NGTLJEFw@mail.gmail.com
From: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
Message-ID: <9df9ea6b-75cb-27bd-79c3-b9145f97e7b3@postgrespro.ru>
Date: Tue, 27 Jul 2021 11:22:05 +0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
 <CAPmGK170Y-6ysT1Vk+dmz4wXBq6Zq4+Sw2kMywsTdXduA0Svyw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/9df9ea6b-75cb-27bd-79c3-b9145f97e7b3%40postgrespro.ru>
Precedence: bulk

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