Re: MERGE issues around inheritance

On Mon, 26 May 2025 at 10:30, jian he <jian.universality@gmail.com> wrote:
>
> + 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?

Good point. I think that's by far the most common case, so that seems
like a worthwhile optimisation. v2 attached.


> we can unconditionally call ExecBuildProjectionInfo for rootRelInfo
> within ExecInitModifyTable instead of in ExecInitMerge.
> right after
>
>         /*
>          * Build a projection for each result rel.
>          */
>         resultRelInfo = mtstate->resultRelInfo;
>         foreach(l, returningLists)
>         {
>             List       *rlist = (List *) lfirst(l);
>             resultRelInfo->ri_returningList = rlist;
>             resultRelInfo->ri_projectReturning =
>                 ExecBuildProjectionInfo(rlist, econtext, slot, &mtstate->ps,
>                                         resultRelInfo->ri_RelationDesc->rd_att);
>             resultRelInfo++;
>         }
>
> This would make related initiation logic stay together, also harmless (i think).
> what do you think?

Well it would have to be done after calling ExecInitMerge() to set up
rootRelInfo->ri_returningList, but I don't think it really makes sense
to do it there. The patch intentionally only does it for a MERGE into
an inherited table when there are INSERT actions, and this also allows
the new code to be more consistent with ExecInitPartitionInfo().

Regards,
Dean