diff options
author | Robert Haas <rhaas@postgresql.org> | 2018-03-22 12:49:48 -0400 |
---|---|---|
committer | Robert Haas <rhaas@postgresql.org> | 2018-03-22 12:49:48 -0400 |
commit | e2f1eb0ee30d144628ab523432320f174a2c8966 (patch) | |
tree | c966ef6a6de9c5e3e4a8c6a0b310cb61306535f5 /src/backend/optimizer/plan/createplan.c | |
parent | 2058d6a22b43a97d1069a51bd95ad56759b3c7bc (diff) | |
download | postgresql-e2f1eb0ee30d144628ab523432320f174a2c8966.tar.gz postgresql-e2f1eb0ee30d144628ab523432320f174a2c8966.zip |
Implement partition-wise grouping/aggregation.
If the partition keys of input relation are part of the GROUP BY
clause, all the rows belonging to a given group come from a single
partition. This allows aggregation/grouping over a partitioned
relation to be broken down * into aggregation/grouping on each
partition. This should be no worse, and often better, than the normal
approach.
If the GROUP BY clause does not contain all the partition keys, we can
still perform partial aggregation for each partition and then finalize
aggregation after appending the partial results. This is less certain
to be a win, but it's still useful.
Jeevan Chalke, Ashutosh Bapat, Robert Haas. The larger patch series
of which this patch is a part was also reviewed and tested by Antonin
Houska, Rajkumar Raghuwanshi, David Rowley, Dilip Kumar, Konstantin
Knizhnik, Pascal Legrand, and Rafia Sabih.
Discussion: http://postgr.es/m/CAM2+6=V64_xhstVHie0Rz=KPEQnLJMZt_e314P0jaT_oJ9MR8A@mail.gmail.com
Diffstat (limited to 'src/backend/optimizer/plan/createplan.c')
-rw-r--r-- | src/backend/optimizer/plan/createplan.c | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index 9ae1bf31d5e..8b4f031d96a 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -1670,7 +1670,15 @@ create_sort_plan(PlannerInfo *root, SortPath *best_path, int flags) subplan = create_plan_recurse(root, best_path->subpath, flags | CP_SMALL_TLIST); - plan = make_sort_from_pathkeys(subplan, best_path->path.pathkeys, NULL); + /* + * make_sort_from_pathkeys() indirectly calls find_ec_member_for_tle(), + * which will ignore any child EC members that don't belong to the given + * relids. Thus, if this sort path is based on a child relation, we must + * pass its relids. + */ + plan = make_sort_from_pathkeys(subplan, best_path->path.pathkeys, + IS_OTHER_REL(best_path->subpath->parent) ? + best_path->path.parent->relids : NULL); copy_generic_path_info(&plan->plan, (Path *) best_path); |