Re: MERGE issues around inheritance

On Mon, 26 May 2025 at 10:30, jian he <jian(dot)universality(at)gmail(dot)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