database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-03 20:02:46 +03:00
Code Activity

Push scan/join target list beneath Gather when possible.

Browse Source 
This means that, for example, "SELECT expensive_func(a) FROM bigtab
WHERE something" can compute expensive_func(a) in the workers rather
than the leader if it happens to be parallel-safe, which figures to be
a big win in some practical cases.

Currently, we can only do this if the entire target list is
parallel-safe.  If we worked harder, we might be able to evaluate
parallel-safe targets in the worker and any parallel-restricted
targets in the leader, but that would be more complicated, and there
aren't that many parallel-restricted functions that people are likely
to use in queries anyway.  I think.  So just do the simple thing for
the moment.

Robert Haas, Amit Kapila, and Tom Lane
This commit is contained in:
Robert Haas
2016-03-18 09:46:40 -04:00
parent 2d8a1e22b1
commit 992b5ba30d
2 changed files with 44 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
src/backend/optimizer/plan/createplan.c
View File

@ -1396,18 +1396,21 @@ create_projection_plan(PlannerInfo *root, ProjectionPath *best_path)
tlist = build_path_tlist(root, &best_path->path);
/*
* Although the ProjectionPath node wouldn't have been made unless its
* pathtarget is different from the subpath's, it can still happen that
* the constructed tlist matches the subplan's. (An example is that
* MergeAppend doesn't project, so we would have thought that we needed a
* projection to attach resjunk sort columns to its output ... but
* create_merge_append_plan might have added those same resjunk sort
* columns to both MergeAppend and its children.) So, if the desired
* tlist is the same expression-wise as the subplan's, just jam it in
* there. We'll have charged for a Result that doesn't actually appear in
* the plan, but that's better than having a Result we don't need.
* We might not really need a Result node here. There are several ways
* that this can happen. For example, MergeAppend doesn't project, so we
* would have thought that we needed a projection to attach resjunk sort
* columns to its output ... but create_merge_append_plan might have
* added those same resjunk sort columns to both MergeAppend and its
* children. Alternatively, apply_projection_to_path might have created
* a projection path as the subpath of a Gather node even though the
* subpath was projection-capable. So, if the subpath is capable of
* projection or the desired tlist is the same expression-wise as the
* subplan's, just jam it in there. We'll have charged for a Result that
* doesn't actually appear in the plan, but that's better than having a
* Result we don't need.
*/
if (tlist_same_exprs(tlist, subplan->targetlist))
if (is_projection_capable_path(best_path->subpath) ||
tlist_same_exprs(tlist, subplan->targetlist))
{
plan = subplan;
plan->targetlist = tlist;