Don't search for volatile expr in find_em_expr_usable_for_sorting_rel
authorTomas Vondra <tomas.vondra@postgresql.org>
Mon, 21 Dec 2020 18:37:14 +0000 (19:37 +0100)
committerTomas Vondra <tomas.vondra@postgresql.org>
Mon, 21 Dec 2020 19:05:11 +0000 (20:05 +0100)
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

src/backend/optimizer/path/equivclass.c

index 0b2e212b2bc1853ba81c99415f233411c2666cda..600fa1263a7f2884859d3ea82d3ded302daa30c3 100644 (file)
@@ -816,8 +816,6 @@ find_em_expr_usable_for_sorting_rel(PlannerInfo *root, EquivalenceClass *ec,
        {
                EquivalenceMember *em = lfirst(lc_em);
                Expr       *em_expr = em->em_expr;
-               PathTarget *target = rel->reltarget;
-               ListCell   *lc_target_expr;
 
                /*
                 * 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,
                 * As long as the expression isn't volatile then
                 * prepare_sort_from_pathkeys is able to generate a new target entry,
                 * so there's no need to verify that one already exists.
+                *
+                * While prepare_sort_from_pathkeys has to be concerned about matching
+                * up a volatile expression to the proper tlist entry, it doesn't seem
+                * valuable here to expend the work trying to find a match in the
+                * target's exprs since such a sort will have to be postponed anyway.
                 */
                if (!ec->ec_has_volatile)
                        return em->em_expr;
-
-               /*
-                * If, however, it's volatile, we have to verify that the
-                * equivalence member's expr is already generated in the
-                * relation's target (we do strip relabels first from both
-                * expressions, which is cheap and might allow us to match
-                * more expressions).
-                */
-               while (em_expr && IsA(em_expr, RelabelType))
-                       em_expr = ((RelabelType *) em_expr)->arg;
-
-               foreach(lc_target_expr, target->exprs)
-               {
-                       Expr       *target_expr = lfirst(lc_target_expr);
-
-                       while (target_expr && IsA(target_expr, RelabelType))
-                               target_expr = ((RelabelType *) target_expr)->arg;
-
-                       if (equal(target_expr, em_expr))
-                               return em->em_expr;
-               }
        }
 
        /* We didn't find any suitable equivalence class expression */