diff options
| author | David Rowley <drowley@postgresql.org> | 2024-04-03 11:40:33 +1300 |
|---|---|---|
| committer | David Rowley <drowley@postgresql.org> | 2024-04-03 11:40:33 +1300 |
| commit | 3b1a7eb28930e9835cda5e42256b7ccc2d044d41 (patch) | |
| tree | e4944e73b9b5018b48c74f0db69d864026dffc4a /src/backend/optimizer/plan/planner.c | |
| parent | 06c418e163e913966e17cb2d3fb1c5f8a8d58308 (diff) | |
| download | postgresql-3b1a7eb28930e9835cda5e42256b7ccc2d044d41.tar.gz postgresql-3b1a7eb28930e9835cda5e42256b7ccc2d044d41.zip | |
Don't zero tuple_fraction when planning UNIONs with ORDER BYs
Since 66c0185a3, the planner is able to use Merge Append -> Unique to
implement UNION queries and each subquery is prompted to produce Paths
correctly sorted by the UNION's targetlist.
Here we remove some now redundant code which was zeroing the
tuple_fraction at the parent level. This will allow the planner to
consider cheap startup paths when planning the UNION's subqueries.
EXCEPT and INTERSECT set operations still have the tuple_fraction zeroed
in generate_nonunion_paths(). These operations currently always read
all of their subqueries' tuples.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/3703023.1711654574@sss.pgh.pa.us
Diffstat (limited to 'src/backend/optimizer/plan/planner.c')
| -rw-r--r-- | src/backend/optimizer/plan/planner.c | 11 |
1 files changed, 0 insertions, 11 deletions
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index dd13852fbdf..d4c13a518fd 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -1339,17 +1339,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction, if (parse->setOperations) { /* - * If there's a top-level ORDER BY, assume we have to fetch all the - * tuples. This might be too simplistic given all the hackery below - * to possibly avoid the sort; but the odds of accurate estimates here - * are pretty low anyway. XXX try to get rid of this in favor of - * letting plan_set_operations generate both fast-start and - * cheapest-total paths. - */ - if (parse->sortClause) - root->tuple_fraction = 0.0; - - /* * Construct Paths for set operations. The results will not need any * work except perhaps a top-level sort and/or LIMIT. Note that any * special work for recursive unions is the responsibility of |