]> granicus.if.org Git - postgresql/commit
Allow child-relation entries to be made in ec_has_const EquivalenceClasses.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 2 Mar 2012 19:28:49 +0000 (14:28 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 2 Mar 2012 19:28:49 +0000 (14:28 -0500)
commitef03b34550e3577c4be3baa25b70787f5646c57b
tree4a4afaf91cba96c452fc5de2510a580514c85840
parentaf1967239a90a5860e2158ebe814a7bcd42e6c6b
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