database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00
Code Activity

Fix interaction of parallel query with prepared statements.

Browse Source 
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.
This commit is contained in:
Robert Haas
2016-12-06 11:11:54 -05:00
parent cb9dcbc1ee
commit 4212cb7326
3 changed files with 14 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
src/backend/executor/execMain.c
View File

@ -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;
/*