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>
From: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
Message-ID: <e5419520-5eff-3f67-8a3f-3e26907a73e2@postgrespro.ru>
Date: Fri, 23 Jul 2021 11:09:35 +0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
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/e5419520-5eff-3f67-8a3f-3e26907a73e2%40postgrespro.ru>
Precedence: bulk

On 7/22/21 4:14 PM, Etsuro Fujita wrote:
> On Fri, Jul 2, 2021 at 10:24 PM Andrey Lepikhov
> @@ -7015,6 +7015,21 @@ process_pending_request(AsyncRequest *areq)
> 
>      fetch_more_data(node);
> 
> +   /*
> +    * If the request are made by another append we will only prepare connection
> +    * for the next query and don't take a tuple immediately. It is needed to
> +    * prevent possible recursion into a qual subplan.
> +    */
> +   if (!fetch)
> +   {
> +       AppendState *node = (AppendState *) areq->requestor;
> +
> +       ExecAsyncRequestDone(areq, NULL);
> +       node->as_needrequest = bms_add_member(node->as_needrequest,
> +                                             areq->request_index);
> +       return;
> +   }
> 
> I don’t think this is a good idea, because it is pretty inconsistent,
> as doing ExecAsyncRequestDone(areq, NULL) means that there are no more
> tuples while changing as_needrequest like that means that there is at
> least one tuple to return.  This would happen to work, but for
> example, if we add to the core more sanity checks on AsyncRequests,
> this would not work well anymore.
I agree.
>  I tried to devise a consistent
> solution for this issue, but I couldn’t.  So I feel inclined to
> disable async execution in cases where async-capable nodes access to
> subplans (or initplans), for now.
I think it can be done, but only as a temporary solution. InitPlan is a 
common planning utility.
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.

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


[1] 
https://www.postgresql.org/message-id/edb1331c-e861-0c53-9fdb-f7ca7dfd884d%40postgrespro.ru

-- 
regards,
Andrey Lepikhov
Postgres Professional