From: Andrey V. Lepikhov <a.lepikhov@postgrespro.ru>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan
Date: Tue, 27 Jul 2021 11:22:05 +0500
Message-ID: <9df9ea6b-75cb-27bd-79c3-b9145f97e7b3@postgrespro.ru> (raw)
In-Reply-To: <CAPmGK170Y-6ysT1Vk+dmz4wXBq6Zq4+Sw2kMywsTdXduA0Svyw@mail.gmail.com>
References: <fe5eaa19-1704-e4a4-76ee-3b9d37ade399@postgrespro.ru>
<CAPmGK170Y-6ysT1Vk+dmz4wXBq6Zq4+Sw2kMywsTdXduA0Svyw@mail.gmail.com>
>> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: a.lepikhov@postgrespro.ru, etsuro.fujita@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan
In-Reply-To: <9df9ea6b-75cb-27bd-79c3-b9145f97e7b3@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox