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

Appearance settings

Commit 9aff4dc

Browse filesBrowse files
committed
Don't search for volatile expr in find_em_expr_usable_for_sorting_rel
While prepare_sort_from_pathkeys has to be concerned about matching up a volatile expression to the proper tlist entry, we don't need to do that in find_em_expr_usable_for_sorting_rel becausee such a sort will have to be postponed anyway. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com
1 parent fac1b47 commit 9aff4dc
Copy full SHA for 9aff4dc

File tree

Expand file treeCollapse file tree

1 file changed

+5
-23
lines changed
Filter options
Expand file treeCollapse file tree

1 file changed

+5
-23
lines changed

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

Copy file name to clipboardExpand all lines: src/backend/optimizer/path/equivclass.c
+5-23Lines changed: 5 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -816,8 +816,6 @@ find_em_expr_usable_for_sorting_rel(PlannerInfo *root, EquivalenceClass *ec,
816816
{
817817
EquivalenceMember *em = lfirst(lc_em);
818818
Expr *em_expr = em->em_expr;
819-
PathTarget *target = rel->reltarget;
820-
ListCell *lc_target_expr;
821819

822820
/*
823821
* We shouldn't be trying to sort by an equivalence class that
@@ -851,30 +849,14 @@ find_em_expr_usable_for_sorting_rel(PlannerInfo *root, EquivalenceClass *ec,
851849
* As long as the expression isn't volatile then
852850
* prepare_sort_from_pathkeys is able to generate a new target entry,
853851
* so there's no need to verify that one already exists.
852+
*
853+
* While prepare_sort_from_pathkeys has to be concerned about matching
854+
* up a volatile expression to the proper tlist entry, it doesn't seem
855+
* valuable here to expend the work trying to find a match in the
856+
* target's exprs since such a sort will have to be postponed anyway.
854857
*/
855858
if (!ec->ec_has_volatile)
856859
return em->em_expr;
857-
858-
/*
859-
* If, however, it's volatile, we have to verify that the
860-
* equivalence member's expr is already generated in the
861-
* relation's target (we do strip relabels first from both
862-
* expressions, which is cheap and might allow us to match
863-
* more expressions).
864-
*/
865-
while (em_expr && IsA(em_expr, RelabelType))
866-
em_expr = ((RelabelType *) em_expr)->arg;
867-
868-
foreach(lc_target_expr, target->exprs)
869-
{
870-
Expr *target_expr = lfirst(lc_target_expr);
871-
872-
while (target_expr && IsA(target_expr, RelabelType))
873-
target_expr = ((RelabelType *) target_expr)->arg;
874-
875-
if (equal(target_expr, em_expr))
876-
return em->em_expr;
877-
}
878860
}
879861

880862
/* We didn't find any suitable equivalence class expression */

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.