diff options
| author | Alexander Korotkov <akorotkov@postgresql.org> | 2025-03-10 13:38:39 +0200 |
|---|---|---|
| committer | Alexander Korotkov <akorotkov@postgresql.org> | 2025-03-10 13:38:39 +0200 |
| commit | fae535da0ac2a8d0bb279cc66d62b0dcc4b5409b (patch) | |
| tree | 8040d2e6c2fd5e6d4a4497b8cdcbdeea9b8f4ea4 /src/backend/optimizer/plan/planner.c | |
| parent | b83e8a2ca2eb381ea0a48e5b2d4e4cdb74febc45 (diff) | |
| download | postgresql-fae535da0ac2a8d0bb279cc66d62b0dcc4b5409b.tar.gz postgresql-fae535da0ac2a8d0bb279cc66d62b0dcc4b5409b.zip | |
Teach Append to consider tuple_fraction when accumulating subpaths.
This change is dedicated to more active usage of IndexScan and parameterized
NestLoop paths in partitioned cases under an Append node, as it already works
with plain tables. As newly added regression tests demonstrate, it should
provide more smartness to the partitionwise technique.
With an indication of how many tuples are needed, it may be more meaningful
to use the 'fractional branch' subpaths of the Append path list, which are
more optimal for this specific number of tuples. Planning on a higher level,
if the optimizer needs all the tuples, it will choose non-fractional paths.
In the case when, during execution, Append needs to return fewer tuples than
declared by tuple_fraction, it would not be harmful to use the 'intermediate'
variant of paths. However, it will earn a considerable profit if a sensible
set of tuples is selected.
The change of the existing regression test demonstrates the positive outcome
of this feature: instead of scanning the whole table, the optimizer prefers
to use a parameterized scan, being aware of the only single tuple the join
has to produce to perform the query.
Discussion: https://www.postgresql.org/message-id/flat/CAN-LCVPxnWB39CUBTgOQ9O7Dd8DrA_tpT1EY3LNVnUuvAX1NjA%40mail.gmail.com
Author: Nikita Malakhov <hukutoc@gmail.com>
Author: Andrei Lepikhov <lepihov@gmail.com>
Reviewed-by: Andy Fan <zhihuifan1213@163.com>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Diffstat (limited to 'src/backend/optimizer/plan/planner.c')
| -rw-r--r-- | src/backend/optimizer/plan/planner.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 36ee6dd43de..014e80c30e6 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -6414,6 +6414,11 @@ make_sort_input_target(PlannerInfo *root, * Find the cheapest path for retrieving a specified fraction of all * the tuples expected to be returned by the given relation. * + * Do not consider parameterized paths. If the caller needs a path for upper + * rel, it can't have parameterized paths. If the caller needs an append + * subpath, it could become limited by the treatment of similar + * parameterization of all the subpaths. + * * We interpret tuple_fraction the same way as grouping_planner. * * We assume set_cheapest() has been run on the given rel. @@ -6436,6 +6441,9 @@ get_cheapest_fractional_path(RelOptInfo *rel, double tuple_fraction) { Path *path = (Path *) lfirst(l); + if (path->param_info) + continue; + if (path == rel->cheapest_total_path || compare_fractional_path_costs(best_path, path, tuple_fraction) <= 0) continue; |