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
