diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-07-03 18:24:49 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-07-03 18:24:49 -0400 |
| commit | 110a6dbdebebac9401b43a8fc223e6ec43cd4d10 (patch) | |
| tree | 5052d014ba377e1be0eef07c8fa925e3309f5394 /src | |
| parent | 4ea9948e58a57316330acb1701f979bc1e872f50 (diff) | |
| download | postgresql-110a6dbdebebac9401b43a8fc223e6ec43cd4d10.tar.gz postgresql-110a6dbdebebac9401b43a8fc223e6ec43cd4d10.zip | |
Allow RTE_SUBQUERY rels to be considered parallel-safe.
There isn't really any reason not to; the original comments here were
partly confused about subplans versus subquery-in-FROM, and partly
dependent on restrictions that no longer apply now that subqueries return
Paths not Plans. Depending on what's inside the subquery, it might fail
to produce any parallel_safe Paths, but that's fine.
Tom Lane and Robert Haas
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/optimizer/path/allpaths.c | 20 |
1 files changed, 12 insertions, 8 deletions
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index 69c7cf64d55..9c6fe752e31 100644 --- a/src/backend/optimizer/path/allpaths.c +++ b/src/backend/optimizer/path/allpaths.c @@ -575,15 +575,19 @@ set_rel_consider_parallel(PlannerInfo *root, RelOptInfo *rel, case RTE_SUBQUERY: /* - * Subplans currently aren't passed to workers. Even if they - * were, the subplan might be using parallelism internally, and we - * can't support nested Gather nodes at present. Finally, we - * don't have a good way of knowing whether the subplan involves - * any parallel-restricted operations. It would be nice to relax - * this restriction some day, but it's going to take a fair amount - * of work. + * There's no intrinsic problem with scanning a subquery-in-FROM + * (as distinct from a SubPlan or InitPlan) in a parallel worker. + * If the subquery doesn't happen to have any parallel-safe paths, + * then flagging it as consider_parallel won't change anything, + * but that's true for plain tables, too. We must set + * consider_parallel based on the rel's own quals and targetlist, + * so that if a subquery path is parallel-safe but the quals and + * projection we're sticking onto it are not, we correctly mark + * the SubqueryScanPath as not parallel-safe. (Note that + * set_subquery_pathlist() might push some of these quals down + * into the subquery itself, but that doesn't change anything.) */ - return; + break; case RTE_JOIN: /* Shouldn't happen; we're only considering baserels here. */ |