On Mon, 26 May 2025 at 07:46, Tender Wang <tndrwang@gmail.com> wrote:
>
> Hi Dean,
>
> "it is possible for the parent to be excluded from the
> plan and so all of the entries in the resultRelInfo array may be for
> different relations than rootResultRelInfo."
>
> I didn't fully understand the above sentence. Can you give me more information or an example?
> If the parent is excluded from the plan, the first entry in the resultRelInfo array will not be the parent but some surviving child.
There's an example in the updated regression tests. A non-inherited
CHECK constraint on the parent causes the planner to exclude the
parent from the relations being scanned and from the resultRelInfo
array, so the first resultRelInfo entry is for a child relation.
Yes, it is. I debugged the updated regression tests. It would crash if resultRelInfo were used instead of rootResultInfo.
Is that the reason that we must use rootResultInfo? Are there other things that I miss?
>That's a different check. "rootRelInfo != mtstate->resultRelInfo"
>checks that we're dealing with an inheritance/partitioned case (see
>the code in ExecInitModifyTable() that sets up rootRelInfo). However,
>in the inherited case, when rootRelInfo and mtstate->resultRelInfo
>point to different ResultRelInfo structures, it is possible (actually
>quite likely) that they will internally point to the same Relation. In
>that case, we do still need to set up the WCO list, RETURNING list and
>projection for rootRelInfo, but we don't need to map attribute
>numbers. Building the attribute map looks like it's O(n^2) in the
>number of attributes, so it's worth avoiding if we can.
Yeah, Jian's idea is right.
--
