Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit44634e4

Browse files
committed
Allow child-relation entries to be made in ec_has_const EquivalenceClasses.
This fixes an oversight in commit11cad29,which introduced MergeAppend plans. Before that happened, we neverparticularly cared about the sort ordering of scans of inheritance childrelations, since appending their outputs together would destroy anyordering anyway. But now it's important to be able to match child relationsort orderings to those of the surrounding query. The original coding ofadd_child_rel_equivalences skipped ec_has_const EquivalenceClasses, on theoriginally-correct grounds that adding child expressions to them wasuseless. The effect of this is that when a parent variable is equated toa constant, we can't recognize that index columns on the equivalent childvariables are not sort-significant; that is, we can't recognize that achild index on, say, (x, y) is able to generate output in "ORDER BY y"order when there is a clause "WHERE x = constant". Adding childexpressions to the (x, constant) EquivalenceClass fixes this, without anydownside that I can see other than a few more planner cycles expended onsuch queries.Per recent gripe from Robert McGehee. Back-patch to 9.1 where MergeAppendwas introduced.
1 parent6688d28 commit44634e4

File tree

1 file changed

+3
-6
lines changed

1 file changed

+3
-6
lines changed

‎src/backend/optimizer/path/equivclass.c

Lines changed: 3 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1785,14 +1785,11 @@ add_child_rel_equivalences(PlannerInfo *root,
17851785
ListCell*lc2;
17861786

17871787
/*
1788-
* If this EC contains a constant, then it's not useful for sorting or
1789-
* driving an inner index-scan, so we skip generating child EMs.
1790-
*
17911788
* If this EC contains a volatile expression, then generating child
1792-
* EMs would be downright dangerous. We rely on a volatile EC having
1793-
* only one EM.
1789+
* EMs would be downright dangerous, so skip it. We rely on a
1790+
*volatile EC havingonly one EM.
17941791
*/
1795-
if (cur_ec->ec_has_const||cur_ec->ec_has_volatile)
1792+
if (cur_ec->ec_has_volatile)
17961793
continue;
17971794

17981795
/* No point in searching if parent rel not mentioned in eclass */

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp