I wrote:
>> It looks like we're somehow triggering the elide-a-left-join code
>> when we shouldn't?
So the reason why we see this with a partitioned target table and not
with a regular target table reduces to this bit in preprocess_targetlist:
/*
* For non-inherited UPDATE/DELETE/MERGE, register any junk column(s)
* needed to allow the executor to identify the rows to be updated or
* deleted. In the inheritance case, we do nothing now, leaving this to
* be dealt with when expand_inherited_rtentry() makes the leaf target
* relations. (But there might not be any leaf target relations, in which
* case we must do this in distribute_row_identity_vars().)
*/
if ((command_type == CMD_UPDATE || command_type == CMD_DELETE ||
command_type == CMD_MERGE) &&
!target_rte->inh)
{
/* row-identity logic expects to add stuff to processed_tlist */
root->processed_tlist = tlist;
add_row_identity_columns(root, result_relation,
target_rte, target_relation);
tlist = root->processed_tlist;
}
This happens before join removal, so that we see use of the row identity
columns of a regular table as a reason not to do join removal. But
expand_inherited_rtentry will happen after that, too late to stop join
removal.
I think the best fix is just to teach join removal that it mustn't
remove the result relation, as attached (needs a regression test).
I'm a little inclined to back-patch this, even though I think it's
probably unreachable in v15. It's a cheap enough safety measure,
and at the very least it will save a few cycles deciding that we
can't remove the target table of a MERGE.
regards, tom lane
diff --git a/src/backend/optimizer/plan/analyzejoins.c b/src/backend/optimizer/plan/analyzejoins.c
index 0dfefd71f2..f79bc4430c 100644
--- a/src/backend/optimizer/plan/analyzejoins.c
+++ b/src/backend/optimizer/plan/analyzejoins.c
@@ -183,6 +183,14 @@ join_is_removable(PlannerInfo *root, SpecialJoinInfo *sjinfo)
if (!bms_get_singleton_member(sjinfo->min_righthand, &innerrelid))
return false;
+ /*
+ * Never try to eliminate a left join to the query result rel. Although
+ * the case is syntactically impossible in standard SQL, MERGE will build
+ * a join tree that looks exactly like that.
+ */
+ if (innerrelid == root->parse->resultRelation)
+ return false;
+
innerrel = find_base_rel(root, innerrelid);
/*