aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2017-08-17 14:04:15 -0400
committerRobert Haas <rhaas@postgresql.org>2017-08-17 14:09:14 -0400
commit1e56883a528eb623c9a55ec7e43b4eee3722014b (patch)
treec8004c2ca390e4a0aa08081b511cb4a91a83b0bc /src
parenta2b70c89ca1a5fcf6181d3c777d82e7b83d2de1b (diff)
downloadpostgresql-1e56883a528eb623c9a55ec7e43b4eee3722014b.tar.gz
postgresql-1e56883a528eb623c9a55ec7e43b4eee3722014b.zip
Attempt to clarify comments related to force_parallel_mode.
Per discussion with Tom Lane. Discussion: http://postgr.es/m/28589.1502902172@sss.pgh.pa.us
Diffstat (limited to 'src')
-rw-r--r--src/backend/optimizer/plan/planner.c22
1 files changed, 15 insertions, 7 deletions
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 407df9ae79d..fdef00ab39c 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -291,13 +291,21 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
}
/*
- * glob->parallelModeNeeded should tell us whether it's necessary to
- * impose the parallel mode restrictions, but we don't actually want to
- * impose them unless we choose a parallel plan, so it is normally set
- * only if a parallel plan is chosen (see create_gather_plan). That way,
- * people who mislabel their functions but don't use parallelism anyway
- * aren't harmed. But when force_parallel_mode is set, we enable the
- * restrictions whenever possible for testing purposes.
+ * glob->parallelModeNeeded is normally set to false here and changed to
+ * true during plan creation if a Gather or Gather Merge plan is actually
+ * created (cf. create_gather_plan, create_gather_merge_plan).
+ *
+ * However, if force_parallel_mode = on or force_parallel_mode = regress,
+ * then we impose parallel mode whenever it's safe to do so, even if the
+ * final plan doesn't use parallelism. It's not safe to do so if the
+ * query contains anything parallel-unsafe; parallelModeOK will be false
+ * in that case. Note that parallelModeOK can't change after this point.
+ * Otherwise, everything in the query is either parallel-safe or
+ * parallel-restricted, and in either case it should be OK to impose
+ * parallel-mode restrictions. If that ends up breaking something, then
+ * either some function the user included in the query is incorrectly
+ * labelled as parallel-safe or parallel-restricted when in reality it's
+ * parallel-unsafe, or else the query planner itself has a bug.
*/
glob->parallelModeNeeded = glob->parallelModeOK &&
(force_parallel_mode != FORCE_PARALLEL_OFF);