On 18/10/2023 16:59, Ashutosh Bapat wrote:
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
<a.lepik...@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
