mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-02-11 19:20:40 +08:00
Code Issues Packages Projects Releases Wiki Activity

Allow child-relation entries to be made in ec_has_const EquivalenceClasses.

Browse Source 
This fixes an oversight in commit 11cad29c91,
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.
This commit is contained in:
Tom Lane 2012-03-02 14:28:46 -05:00
parent 6688d2878e
commit 44634e474f
1 changed files with 3 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/optimizer/path/equivclass.c
View File

@ -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 */