Restructure code that is responsible for ensuring that clauseless joins are

considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct).  The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report.  His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there.  (See the example case added to the join
regression test.)  On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was.  There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not.  It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction.  I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.

Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.

Author: tglsfdc

src/backend/optimizer/README

@@ -105,12 +105,16 @@ that are either base rels or joinrels constructed per sub-join-lists.
 We can join these rels together in any order the planner sees fit.
 The standard (non-GEQO) planner does this as follows:
 
-Consider joining each RelOptInfo to each other RelOptInfo specified in its
-RelOptInfo.joininfo, and generate a Path for each possible join method for
-each such pair.  (If we have a RelOptInfo with no join clauses, we have no
-choice but to generate a clauseless Cartesian-product join; so we consider
-joining that rel to each other available rel.  But in the presence of join
-clauses we will only consider joins that use available join clauses.)
+Consider joining each RelOptInfo to each other RelOptInfo for which there
+is a usable joinclause, and generate a Path for each possible join method
+for each such pair.  (If we have a RelOptInfo with no join clauses, we have
+no choice but to generate a clauseless Cartesian-product join; so we
+consider joining that rel to each other available rel.  But in the presence
+of join clauses we will only consider joins that use available join
+clauses.  Note that join-order restrictions induced by outer joins and
+IN clauses are treated as if they were real join clauses, to ensure that
+we find a workable join order in cases where those restrictions force a
+clauseless join to be done.)
 
 If we only had two relations in the list, we are done: we just pick
 the cheapest path for the join RelOptInfo.  If we had more than two, we now

src/backend/optimizer/geqo/geqo_eval.c

@@ -6,7 +6,7 @@
  * Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_eval.c,v 1.84 2007/02/13 02:31:02 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_eval.c,v 1.85 2007/02/16 00:14:01 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -253,52 +253,14 @@ static bool
 desirable_join(PlannerInfo *root,
 			   RelOptInfo *outer_rel, RelOptInfo *inner_rel)
 {
-	ListCell   *l;
-
 	/*
-	 * Join if there is an applicable join clause.
+	 * Join if there is an applicable join clause, or if there is a join
+	 * order restriction forcing these rels to be joined.
 	 */
-	if (have_relevant_joinclause(root, outer_rel, inner_rel))
+	if (have_relevant_joinclause(root, outer_rel, inner_rel) ||
+		have_join_order_restriction(root, outer_rel, inner_rel))
 		return true;
 
-	/*
-	 * Join if the rels overlap the same outer-join side and don't already
-	 * implement the outer join. This is needed to ensure that we can find a
-	 * valid solution in a case where an OJ contains a clauseless join.
-	 */
-	foreach(l, root->oj_info_list)
-	{
-		OuterJoinInfo *ojinfo = (OuterJoinInfo *) lfirst(l);
-
-		/* ignore full joins --- other mechanisms preserve their ordering */
-		if (ojinfo->is_full_join)
-			continue;
-		if (bms_overlap(outer_rel->relids, ojinfo->min_righthand) &&
-			bms_overlap(inner_rel->relids, ojinfo->min_righthand) &&
-			!bms_overlap(outer_rel->relids, ojinfo->min_lefthand) &&
-			!bms_overlap(inner_rel->relids, ojinfo->min_lefthand))
-			return true;
-		if (bms_overlap(outer_rel->relids, ojinfo->min_lefthand) &&
-			bms_overlap(inner_rel->relids, ojinfo->min_lefthand) &&
-			!bms_overlap(outer_rel->relids, ojinfo->min_righthand) &&
-			!bms_overlap(inner_rel->relids, ojinfo->min_righthand))
-			return true;
-	}
-
-	/*
-	 * Join if the rels are members of the same IN sub-select. This is needed
-	 * to ensure that we can find a valid solution in a case where an IN
-	 * sub-select has a clauseless join.
-	 */
-	foreach(l, root->in_info_list)
-	{
-		InClauseInfo *ininfo = (InClauseInfo *) lfirst(l);
-
-		if (bms_is_subset(outer_rel->relids, ininfo->righthand) &&
-			bms_is_subset(inner_rel->relids, ininfo->righthand))
-			return true;
-	}
-
 	/* Otherwise postpone the join till later. */
 	return false;
 }