From d7a6a04dc75ebf19cc97d65977801a63756582d9 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 16 Apr 2009 20:42:16 +0000 Subject: Fix planner to restore its previous level of intelligence about pushing constants through full joins, as in select * from tenk1 a full join tenk1 b using (unique1) where unique1 = 42; which should generate a fairly cheap plan where we apply the constraint unique1 = 42 in each relation scan. This had been broken by my patch of 2008-06-27, which is now reverted in favor of a more invasive but hopefully less incorrect approach. That patch was meant to prevent incorrect extraction of OR'd indexclauses from OR conditions above an outer join. To do that correctly we need more information than the outerjoin_delay flag can provide, so add a nullable_relids field to RestrictInfo that records exactly which relations are nulled by outer joins that are underneath a particular qual clause. A side benefit is that we can make the test in create_or_index_quals more specific: it is now smart enough to extract an OR'd indexclause into the outer side of an outer join, even though it must not do so in the inner side. The old coding couldn't distinguish these cases so it could not do either. --- src/include/nodes/relation.h | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) (limited to 'src/include/nodes/relation.h') diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h index cf567b9974..6a72504a2f 100644 --- a/src/include/nodes/relation.h +++ b/src/include/nodes/relation.h @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.171 2009/03/26 17:15:35 tgl Exp $ + * $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.172 2009/04/16 20:42:16 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -920,8 +920,14 @@ typedef struct HashPath * * RestrictInfo nodes also contain an outerjoin_delayed flag, which is true * if the clause's applicability must be delayed due to any outer joins - * appearing below its own syntactic level (ie, it references any Vars from - * the nullable side of any lower outer join). + * appearing below it (ie, it has to be postponed to some join level higher + * than the set of relations it actually references). There is also a + * nullable_relids field, which is the set of rels it references that can be + * forced null by some outer join below the clause. outerjoin_delayed = true + * is subtly different from nullable_relids != NULL: a clause might reference + * some nullable rels and yet not be outerjoin_delayed because it also + * references all the other rels of the outer join(s). A clause that is not + * outerjoin_delayed can be enforced anywhere it is computable. * * In general, the referenced clause might be arbitrarily complex. The * kinds of clauses we can handle as indexscan quals, mergejoin clauses, @@ -983,6 +989,9 @@ typedef struct RestrictInfo /* The set of relids required to evaluate the clause: */ Relids required_relids; + /* The relids used in the clause that are nullable by lower outer joins: */ + Relids nullable_relids; + /* These fields are set for any binary opclause: */ Relids left_relids; /* relids in left side of clause */ Relids right_relids; /* relids in right side of clause */ -- cgit v1.2.1