diff options
| author | Tomas Vondra <tomas.vondra@postgresql.org> | 2020-12-21 18:29:46 +0100 |
|---|---|---|
| committer | Tomas Vondra <tomas.vondra@postgresql.org> | 2020-12-21 18:42:58 +0100 |
| commit | be9c3cd186ba86b9bc3df7ecc64b81ce4726810d (patch) | |
| tree | 1db8f5cfe29de9e55581bb828af88b8ee67a2d2d /src/backend/optimizer/path/equivclass.c | |
| parent | ea190ed14b4b75b38a490707d5d08231dcacfb8c (diff) | |
Check parallel safety in generate_useful_gather_paths
Commit ebb7ae839d ensured we ignore pathkeys with volatile expressions
when considering adding a sort below a Gather Merge. Turns out we need
to care about parallel safety of the pathkeys too, otherwise we might
try sorting e.g. on results of a correlated subquery (as demonstrated
by a report from Luis Roberto).
Initial investigation by Tom Lane, patch by James Coleman. Backpatch
to 13, where the code was instroduced (as part of Incremental Sort).
Reported-by: Luis Roberto
Author: James Coleman
Reviewed-by: Tomas Vondra
Backpatch-through: 13
Discussion: https://postgr.es/m/622580997.37108180.1604080457319.JavaMail.zimbra%40siscobra.com.br
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=H5M8LSchj5e5OxpTAg@mail.gmail.com
Diffstat (limited to 'src/backend/optimizer/path/equivclass.c')
| -rw-r--r-- | src/backend/optimizer/path/equivclass.c | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/src/backend/optimizer/path/equivclass.c b/src/backend/optimizer/path/equivclass.c index 130f482eb62..a0a4699c813 100644 --- a/src/backend/optimizer/path/equivclass.c +++ b/src/backend/optimizer/path/equivclass.c @@ -800,7 +800,8 @@ find_em_expr_for_rel(EquivalenceClass *ec, RelOptInfo *rel) * applied in prepare_sort_from_pathkeys. */ Expr * -find_em_expr_usable_for_sorting_rel(EquivalenceClass *ec, RelOptInfo *rel) +find_em_expr_usable_for_sorting_rel(PlannerInfo *root, EquivalenceClass *ec, + RelOptInfo *rel, bool require_parallel_safe) { ListCell *lc_em; @@ -831,6 +832,12 @@ find_em_expr_usable_for_sorting_rel(EquivalenceClass *ec, RelOptInfo *rel) continue; /* + * If requested, reject expressions that are not parallel-safe. + */ + if (require_parallel_safe && !is_parallel_safe(root, (Node *) em_expr)) + continue; + + /* * 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. |