Re: Asymmetric partition-wise JOIN

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