]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Prevent join removal from removing the query's result relation.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 20 Feb 2023 20:18:22 +0000 (15:18 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 20 Feb 2023 20:18:32 +0000 (15:18 -0500)
commite6d8639cf25ccfffe12695768a4f7a60130c426f
tree20a23fbd0743fda124829443ce7d9afb0070b9ed
parentda32a99df1f519622eee0d5c3ea61226468272a7
Prevent join removal from removing the query's result relation.

This was not something that required consideration before MERGE
was invented; but MERGE builds a join tree that left-joins to the
result relation, meaning that remove_useless_joins will consider
removing it.  That should generally be stopped by the query's use
of output variables from the result relation.  However, if the
result relation is inherited (e.g. a partitioned table) then
we don't add any row identity variables to the query until
expand_inherited_rtentry, which happens after join removal.

This was exposed as of commit 3c569049b, which made it possible
to deduce that a partitioned table could contain at most one row
matching a join key, enabling removal of the not-yet-expanded
result relation.  Ooops.

To fix, let's just teach join_is_removable that the query result
rel is never removable.  It's a cheap enough test in any case,
and it'll save some cycles that we'd otherwise expend in proving
that it's not removable, even in the cases we got right.

Back-patch to v15 where MERGE was added.  Although I think the
case cannot be reached in v15, this seems like cheap insurance.

Per investigation of a report from Alexander Lakhin.

Discussion: https://postgr.es/m/36bee393-b351-16ac-93b2-d46d83637e45@gmail.com
src/backend/optimizer/plan/analyzejoins.c
src/test/regress/expected/merge.out
src/test/regress/sql/merge.sql