pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrey V. Lepikhov <a.lepikhov@postgrespro.ru>
To: pgsql-bugs@lists.postgresql.org
Subject: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan
Date: Tue, 27 Jul 2021 16:00:39 +0500
Message-ID: <bca32a14-3314-db8a-6b4f-97caa92aa214@postgrespro.ru> (raw)
In-Reply-To: <CAPmGK17+CXJXs-+TGxqdzG=KKbOtiB5cWDSUKEMqfsFH2Lo-Gw@mail.gmail.com>
References: <fe5eaa19-1704-e4a4-76ee-3b9d37ade399@postgrespro.ru>
	<CAPmGK170Y-6ysT1Vk+dmz4wXBq6Zq4+Sw2kMywsTdXduA0Svyw@mail.gmail.com>
	<9df9ea6b-75cb-27bd-79c3-b9145f97e7b3@postgrespro.ru>
	<CAPmGK17+CXJXs-+TGxqdzG=KKbOtiB5cWDSUKEMqfsFH2Lo-Gw@mail.gmail.com>

On 7/27/21 3:50 PM, Etsuro Fujita wrote:
> On Tue, Jul 27, 2021 at 3:22 PM Andrey V. Lepikhov
> <a.lepikhov@postgrespro.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





view thread (20+ messages)  latest in thread

Message-ID: <bca32a14-3314-db8a-6b4f-97caa92aa214@postgrespro.ru>
Permalink:  ../bca32a14-3314-db8a-6b4f-97caa92aa214@postgrespro.ru/
Also on:    postgresql.org/message-id/bca32a14-3314-db8a-6b4f-97caa92aa214@postgrespro.ru

 · 

reply

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, pgsql-bugs@lists.postgresql.org
  Subject: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan
  In-Reply-To: <bca32a14-3314-db8a-6b4f-97caa92aa214@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