Dean Rasheed <dean.a.rash...@gmail.com> 于2025年5月26日周一 18:41写道：
> On Mon, 26 May 2025 at 07:46, Tender Wang <tndrw...@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. -- Thanks, Tender Wang
