postgres.git / summary / log / commit / refs

commit    4212cb73262bbdd164727beffa4c4744b4ead92d
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Tue Dec 06 16:11:54 2016 +0000

    Fix interaction of parallel query with prepared statements.
    
    Previously, a prepared statement created via a Parse message could get
    a parallel plan, but one created with a PREPARE statement could not.
    This state of affairs was due to confusion on my (rhaas) part: I
    erroneously believed that a CREATE TABLE .. AS EXECUTE statement could
    only be performed with a prepared statement by PREPARE, but in fact
    one created by a Prepare message works just as well.  Therefore, it
    makes no sense to allow parallel query in one case but not the other.
    
    To fix, allow parallel query with all prepared statements, but run
    the parallel plan serially (i.e. without workers) in the case of
    CREATE TABLE .. AS EXECUTE.  Also, document this.
    
    Amit Kapila and Tobias Bussman, plus an extra sentence of
    documentation by me.


 doc/src/sgml/parallel.sgml      | 9 +++++++++
 src/backend/commands/prepare.c  | 2 +-
 src/backend/executor/execMain.c | 7 ++++---
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index f39c21a4550..cf4c1c9c2a9 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -227,6 +227,15 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
       </para>
     </listitem>
 
+    <listitem>
+      <para> 
+        A prepared statement is executed using a <literal>CREATE TABLE .. AS
+        EXECUTE ..</literal> statement.  This construct converts what otherwise
+        would have been a read-only operation into a read-write operation,
+        making it ineligible for parallel query.
+      </para>
+    </listitem>
+
     <listitem>
       <para> 
         The transaction isolation level is serializable.  This situation
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index cec37ce0405..b01051df9d2 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -159,7 +159,7 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
 					   nargs,
 					   NULL,
 					   NULL,
-					   0,		/* default cursor options */
+					   CURSOR_OPT_PARALLEL_OK,	/* allow parallel mode */
 					   true);	/* fixed result */
 
 	/*
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 32bb3f92054..71c07288a19 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -1540,10 +1540,11 @@ ExecutePlan(EState *estate,
 	estate->es_direction = direction;
 
 	/*
-	 * If a tuple count was supplied, we must force the plan to run without
-	 * parallelism, because we might exit early.
+	 * If a tuple count was supplied or data is being written to relation, we
+	 * must force the plan to run without parallelism, because we might exit
+	 * early.
 	 */
-	if (numberTuples)
+	if (numberTuples || dest->mydest == DestIntoRel)
 		use_parallel_mode = false;
 
 	/*


[parent: cb9dcbc1eebd]