Skip site navigation (1) Skip section navigation (2)

pgsql: Allow child-relation entries to be made in ec_has_constEquivale

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Allow child-relation entries to be made in ec_has_constEquivale
Date: 2012-03-02 19:29:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committers
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.



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

pgsql-committers by date

Next:From: Peter EisentrautDate: 2012-03-02 20:12:20
Subject: pgsql: Re-add "make check" target in src/test/isolation/Makefile
Previous:From: Peter EisentrautDate: 2012-03-02 19:18:24
Subject: pgsql: Add COLLATION FOR expression

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group