Robert Haas <robertmhaas@gmail.com> writes:
> In practice, we don't yet have the ability for
> parallel-safe paths from subqueries to affect planning at higher query
> levels, but that's because the pathification stuff landed too late in
> the cycle for me to fully react to it.
I wonder if that's not just from confusion between subplans and
subqueries. I don't believe any of the claims made in the comment
adjusted in the patch below (other than "Subplans currently aren't passed
to workers", which is true but irrelevant). Nested Gather nodes is
something that you would need, and already have, a defense for anyway.
regards, tom lane
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index cc8ba61..8ab049c 100644
*** a/src/backend/optimizer/path/allpaths.c
--- b/src/backend/optimizer/path/allpaths.c
*************** set_rel_consider_parallel(PlannerInfo *r
*** 560,574 ****
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.
*/
! return;
case RTE_JOIN:
/* Shouldn't happen; we're only considering baserels here. */
--- 560,574 ----
case RTE_SUBQUERY:
/*
! * If the subquery doesn't have anything parallel-restricted, we
! * can consider parallel scans. Note that this does not mean that
! * all (or even any) of the paths produced for the subquery will
! * actually be parallel-safe; but that's true for paths produced
! * for regular tables, too.
*/
! if (has_parallel_hazard((Node *) rte->subquery, false))
! return;
! break;
case RTE_JOIN:
/* Shouldn't happen; we're only considering baserels here. */
