Re: MERGE issues around inheritance - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: MERGE issues around inheritance
Date
Msg-id CAEZATCXXjDwoq5aXeCy1-W7HkT2rQ0q3bbbhqSbUEJDWPv10pg@mail.gmail.com
Whole thread Raw
In response to Re: MERGE issues around inheritance  (Tender Wang <tndrwang@gmail.com>)
List pgsql-hackers
On Mon, 26 May 2025 at 10:39, Tender Wang <tndrwang@gmail.com> wrote:
>
> jian he <jian.universality@gmail.com> 于2025年5月26日周一 17:30写道:
>>
>> + Relation rootRelation = rootRelInfo->ri_RelationDesc;
>> + Relation firstResultRel = mtstate->resultRelInfo[0].ri_RelationDesc;
>> + int firstVarno = mtstate->resultRelInfo[0].ri_RangeTableIndex;
>>
>> firstResultRel may equal (==) to rootRelation,
>> in that case, we don't need to call map_variable_attnos?
>>
> +       if (rootRelInfo != mtstate->resultRelInfo &&
> +               rootRelInfo->ri_RelationDesc->rd_rel->relkind != RELKIND_PARTITIONED_TABLE &&
> +               (mtstate->mt_merge_subcommands & MERGE_INSERT) != 0)
>
> Above if already does the check.

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.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: MERGE issues around inheritance
Next
From: Shubhankar Anand Kulkarni
Date:
Subject: Re: Expression push down from Join Node to below node.