postgres.git / summary / log / commit / refs

commit    ef03b34550e3577c4be3baa25b70787f5646c57b
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Fri Mar 02 19:28:49 2012 +0000
First released in: 9.2.0, 9.1.4

    Allow child-relation entries to be made in ec_has_const EquivalenceClasses.
    
    This fixes an oversight in commit 11cad29c91524aac1d0b61e0ea0357398ab79bf8,
    which introduced MergeAppend plans.  Before that happened, we never
    particularly cared about the sort ordering of scans of inheritance child
    relations, since appending their outputs together would destroy any
    ordering anyway.  But now it's important to be able to match child relation
    sort orderings to those of the surrounding query.  The original coding of
    add_child_rel_equivalences skipped ec_has_const EquivalenceClasses, on the
    originally-correct grounds that adding child expressions to them was
    useless.  The effect of this is that when a parent variable is equated to
    a constant, we can't recognize that index columns on the equivalent child
    variables are not sort-significant; that is, we can't recognize that a
    child index on, say, (x, y) is able to generate output in "ORDER BY y"
    order when there is a clause "WHERE x = constant".  Adding child
    expressions to the (x, constant) EquivalenceClass fixes this, without any
    downside that I can see other than a few more planner cycles expended on
    such queries.
    
    Per recent gripe from Robert McGehee.  Back-patch to 9.1 where MergeAppend
    was introduced.


 src/backend/optimizer/path/equivclass.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/backend/optimizer/path/equivclass.c b/src/backend/optimizer/path/equivclass.c
index acc4fb1a185..469d376ad29 100644
--- a/src/backend/optimizer/path/equivclass.c
+++ b/src/backend/optimizer/path/equivclass.c
@@ -1785,14 +1785,11 @@ add_child_rel_equivalences(PlannerInfo *root,
 		ListCell   *lc2;
 
 		/*
-		 * If this EC contains a constant, then it's not useful for sorting or
-		 * driving an inner index-scan, so we skip generating child EMs.
-		 *
 		 * If this EC contains a volatile expression, then generating child
-		 * EMs would be downright dangerous.  We rely on a volatile EC having
-		 * only one EM.
+		 * EMs would be downright dangerous, so skip it.  We rely on a
+		 * volatile EC having only one EM.
 		 */
-		if (cur_ec->ec_has_const || cur_ec->ec_has_volatile)
+		if (cur_ec->ec_has_volatile)
 			continue;
 
 		/* No point in searching if parent rel not mentioned in eclass */


[parent: af1967239a90]