Rethink treatment of "postponed" quals in deconstruct_jointree().
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 4 Feb 2023 17:45:53 +0000 (12:45 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 4 Feb 2023 17:45:53 +0000 (12:45 -0500)
commit5840c2027264d5dfad743c50874e0ebf8b840f3f
tree83a185563f0c66f5e9f8f56a2e2a9e57ae0a3841
parentfaff8f8e47f18c7d589453e2e0d841d2bd96c1ac
Rethink treatment of "postponed" quals in deconstruct_jointree().

After pulling up LATERAL subqueries, we may have qual clauses that
refer to relations outside their syntactic scope.  Before doing any
such pullup, prepjointree.c checks to make sure that it wouldn't
create a semantically-invalid situation; but we leave it to
deconstruct_jointree() to actually move these quals up the join
tree to a place where they can be evaluated.  In commit 2489d76c4,
I (tgl) refactored deconstruct_jointree() in a way that caused
assertion failures while moving such quals, because the new logic
failed to distinguish "this jointree node is a parent of the source
one" from "this jointree node is processed after the source
one in depth-first order".

Fix this, and at the same time reduce the overhead a bit, by
getting rid of the common PostponedQual list and instead making each
JoinTreeItem contain a list of quals that needed to be postponed to
its level.  We can help distribute_qual_to_rels find the appropriate
JoinTreeItem efficiently by adding parent-item links to the
JoinTreeItem data structure.  This ends up being the same number
of relid subset checks as the original (pre-bug) logic, but less
list manipulation is required during multi-level postponements.

Richard Guo and Tom Lane, per bug #17768 from Robins Tharakan.

Discussion: https://postgr.es/m/17768-5ac8730ece54478f@postgresql.org
src/backend/optimizer/plan/initsplan.c
src/test/regress/expected/join.out
src/test/regress/sql/join.sql