database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-31 17:02:12 +03:00
Code Activity

Disallow SRFs when considering sorts below Gather Merge

Browse Source 
While we do allow SRFs in ORDER BY, scan/join processing should not
consider such cases - such sorts should only happen via final Sort atop
a ProjectSet. So make sure we don't try adding such sorts below Gather
Merge, just like we do for expressions that are volatile and/or not
parallel safe.

Backpatch to PostgreSQL 13, where this code was introduced as part of
the Incremental Sort patch.

Author: James Coleman
Reviewed-by: Tomas Vondra
Backpatch-through: 13
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=H5M8LSchj5e5OxpTAg@mail.gmail.com
Discussion: https://postgr.es/m/295524.1606246314%40sss.pgh.pa.us
This commit is contained in:
Tomas Vondra
2020-12-21 18:58:32 +01:00
parent ff5d5611c0
commit fac1b470a9
5 changed files with 26 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -840,6 +840,13 @@ find_em_expr_usable_for_sorting_rel(PlannerInfo *root, EquivalenceClass *ec,
if (require_parallel_safe && !is_parallel_safe(root, (Node *) em_expr))
continue;
/*
* Disallow SRFs so that all of them can be evaluated at the correct
* time as determined by make_sort_input_target.
*/
if (IS_SRF_CALL((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,