Message-ID: <9b066451-8f83-4f82-aeb2-bfcb5928cb41@postgrespro.ru>
Date: Thu, 19 Oct 2023 11:04:52 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Asymmetric partition-wise JOIN
Content-Language: en-US
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Alexander Pyhalov <a.pyhalov@postgrespro.ru>,
 Jaime Casanova <jcasanov@systemguards.com.ec>,
 Aleksander Alekseev <afiskon@gmail.com>, pgsql-hackers@lists.postgresql.org,
 KaiGai Kohei <kaigai@heterodb.com>, "a.rybakina"
 <a.rybakina@postgrespro.ru>,
 =?UTF-8?B?0JHQtdC70Y/Qu9C+0LIg0JTQsNC80LjRgCDQndCw0LjQu9C10LLQuNGH?=
 <d.belyalov@postgrespro.ru>
References: 
 <CAOP8fzaVL_2SCJayLL9kj5pCA46PJOXXjuei6-3aFUV45j4LJQ@mail.gmail.com>
 <CALtqXTfhC=FfHe0+_RP84w=X13d+z+akyN_ROCEQAyQigW7PDA@mail.gmail.com>
 <163118104689.1167.8241611097516113795.pgcf@coridan.postgresql.org>
 <20210909153833.GA6514@ahch-to>
 <2c9caede-55c0-2042-e421-dd0021f28837@postgrespro.ru>
 <792d60f4-37bc-e6ad-68ca-c2af5cbb2d9b@postgrespro.ru>
 <88bc3c051d285653215393a56bdf3056@postgrespro.ru>
 <CAPpHfdtm2_xM1WP1=Jyj9vRQ5jNu-kSqaoazvUp_s_7Cq0906A@mail.gmail.com>
 <5c0e38e3-7ab5-4b10-a1bb-70ca69771ff0@postgrespro.ru>
 <CAPpHfdvwp7cBWs=iBv7zc7e9NOWQf0TmcwNNzw=--H1qFoBcNA@mail.gmail.com>
 <521c2a71-49dd-4ab5-a585-569d0af3a647@postgrespro.ru>
 <CAExHW5vOGLD5MUW2tMTYR8pSjcT67+RVRyDy99fUSCKsdBELaA@mail.gmail.com>
 <a4fe3652-a0a0-4482-8a7e-15024671b53e@postgrespro.ru>
 <CAExHW5uOSp9LZKAsb2ejn+PRNshyAruGppAmAef=wdhRrQ=rqQ@mail.gmail.com>
 <d99ed0cb-c1b0-4da0-a9f7-b7061cb497bb@postgrespro.ru>
 <CAExHW5tr0mdEzjGth4mFNPcOBxrU=VfH5zhakg9RKeW5HZq5ng@mail.gmail.com>
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
In-Reply-To: 
 <CAExHW5tr0mdEzjGth4mFNPcOBxrU=VfH5zhakg9RKeW5HZq5ng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/9b066451-8f83-4f82-aeb2-bfcb5928cb41%40postgrespro.ru>
Precedence: bulk

On 18/10/2023 16:59, Ashutosh Bapat wrote:
> On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
> <a.lepikhov@postgrespro.ru> wrote:
>>
>>> But the clauses of A parameterized by P will produce different
>>> translations for each of the partitions. I think we will need
>>> different RelOptInfos (for A) to store these translations.
>>
>> Does the answer above resolved this issue?
> 
> May be. There are other problematic areas like EvalPlanQual, Rescans,
> reparameterised paths which can blow up if we use the same RelOptInfo
> for different scans of the same relation. It will be good to test

Yeah, now I got it. It is already the second place where I see some 
reference to a kind of hidden rule that the rte entry (or RelOptInfo) 
must correspond to only one plan node. I don't have a quick answer for 
now - maybe it is a kind of architectural agreement - and I will 
consider this issue during the development.

> those. And also A need not be a simple relation; it could be join as
> well.

For a join RelOptInfo, as well as for any subtree, we have the same 
logic: the pathlist of this subtree is already formed during the 
previous level of the search and will not be changed.

>>
>>> The relid is also used to track the scans at executor level. Since we
>>> have so many scans on A, each may be using different plan, we will
>>> need different ids for those.
>>
>> I don't understand this sentence. Which way executor uses this index of
>> RelOptInfo ?
> 
> See Scan::scanrelid
> 

-- 
regards,
Andrey Lepikhov
Postgres Professional