Enable parallelism for prepared statements and extended query protocol.
authorRobert Haas
Thu, 25 Feb 2016 07:32:18 +0000 (13:02 +0530)
committerRobert Haas
Thu, 25 Feb 2016 07:32:18 +0000 (13:02 +0530)
Parallel query can't handle running a query only partially rather than
to completion.  However, there seems to be no way to run a statement
prepared via SQL PREPARE other than to completion, so we can enable it
there without a problem.

The situation is more complicated for the extend query protocol.
libpq seems to provide no way to send an Execute message with a
non-zero rowcount, but some other client might.  If that happens, and
a parallel plan was chosen, we'll execute the parallel plan without
using any workers, which may be somewhat inefficient but should still
work.  Hopefully this won't be a problem; users can always set
max_parallel_degree=0 to avoid choosing parallel plans in the first
place.

Amit Kapila, reviewed by me.

src/backend/commands/prepare.c
src/backend/tcop/postgres.c

index cec37ce0405739d42732848ae08eef58dfa3daaa..b01051df9d2f942d14a7d102fec97274f6342c05 100644 (file)
@@ -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 */
 
    /*
index 390816bb9c2615f03f89a1723e93e33dc71be4df..115166b6f6adcd12e1f90bb3164da8b0c7b84149 100644 (file)
@@ -1381,7 +1381,7 @@ exec_parse_message(const char *query_string,  /* string to execute */
                       numParams,
                       NULL,
                       NULL,
-                      0,       /* default cursor options */
+                      CURSOR_OPT_PARALLEL_OK,  /* allow parallel mode */
                       true);   /* fixed result */
 
    /* If we got a cancel signal during analysis, quit */