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

Don't generate parallel paths for rels with parallel-restricted outputs.

Browse Source 
Such paths are unsafe.  To make it cheaper to detect when this case
applies, track whether a relation's default PathTarget contains any
non-Vars.  In most cases, the answer will be no, which enables us to
determine cheaply that the target list for a proposed path is
parallel-safe.  However, subquery pull-up can create cases that
require us to inspect the target list more carefully.

Amit Kapila, reviewed by me.
This commit is contained in:
Robert Haas
2016-06-09 12:40:23 -04:00
parent e7bcd983f5
commit b12fd41c69
5 changed files with 22 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/optimizer/path/allpaths.c
View File

@ -608,6 +608,15 @@ set_rel_consider_parallel(PlannerInfo *root, RelOptInfo *rel,
if (has_parallel_hazard((Node *) rel->baserestrictinfo, false))
return;
/*
* If the relation's outputs are not parallel-safe, we must give up.
* In the common case where the relation only outputs Vars, this check is
* very cheap; otherwise, we have to do more work.
*/
if (rel->reltarget_has_non_vars &&
has_parallel_hazard((Node *) rel->reltarget->exprs, false))
return;
/* We have a winner. */
rel->consider_parallel = true;
}
@ -971,6 +980,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
adjust_appendrel_attrs(root,
(Node *) rel->reltarget->exprs,
appinfo);
childrel->reltarget_has_non_vars = rel->reltarget_has_non_vars;
/*
* We have to make child entries in the EquivalenceClass data