diff options
author | Robert Haas <rhaas@postgresql.org> | 2017-03-23 13:05:48 -0400 |
---|---|---|
committer | Robert Haas <rhaas@postgresql.org> | 2017-03-23 13:14:36 -0400 |
commit | 691b8d59281b5177f16fe80858df921f77a8e955 (patch) | |
tree | 8708ae434bf120e73f93e3ef43779d761438ba79 /src/backend/tcop/pquery.c | |
parent | 218f51584d5a9fcdf702bcc7f54b5b65e255c187 (diff) |
Allow for parallel execution whenever ExecutorRun() is done only once.
Previously, it was unsafe to execute a plan in parallel if
ExecutorRun() might be called with a non-zero row count. However,
it's quite easy to fix things up so that we can support that case,
provided that it is known that we will never call ExecutorRun() a
second time for the same QueryDesc. Add infrastructure to signal
this, and cross-checks to make sure that a caller who claims this is
true doesn't later reneg.
While that pattern never happens with queries received directly from a
client -- there's no way to know whether multiple Execute messages
will be sent unless the first one requests all the rows -- it's pretty
common for queries originating from procedural languages, which often
limit the result to a single tuple or to a user-specified number of
tuples.
This commit doesn't actually enable parallelism in any additional
cases, because currently none of the places that would be able to
benefit from this infrastructure pass CURSOR_OPT_PARALLEL_OK in the
first place, but it makes it much more palatable to pass
CURSOR_OPT_PARALLEL_OK in places where we currently don't, because it
eliminates some cases where we'd end up having to run the parallel
plan serially.
Patch by me, based on some ideas from Rafia Sabih and corrected by
Rafia Sabih based on feedback from Dilip Kumar and myself.
Discussion: http://postgr.es/m/CA+TgmobXEhvHbJtWDuPZM9bVSLiTj-kShxQJ2uM5GPDze9fRYA@mail.gmail.com
Diffstat (limited to 'src/backend/tcop/pquery.c')
-rw-r--r-- | src/backend/tcop/pquery.c | 20 |
1 files changed, 16 insertions, 4 deletions
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c index 371d7350b7a..f538b7787c3 100644 --- a/src/backend/tcop/pquery.c +++ b/src/backend/tcop/pquery.c @@ -90,6 +90,9 @@ CreateQueryDesc(PlannedStmt *plannedstmt, qd->planstate = NULL; qd->totaltime = NULL; + /* not yet executed */ + qd->already_executed = false; + return qd; } @@ -152,7 +155,7 @@ ProcessQuery(PlannedStmt *plan, /* * Run the plan to completion. */ - ExecutorRun(queryDesc, ForwardScanDirection, 0L); + ExecutorRun(queryDesc, ForwardScanDirection, 0L, true); /* * Build command completion status string, if caller wants one. @@ -679,7 +682,7 @@ PortalSetResultFormat(Portal portal, int nFormats, int16 *formats) * suspended due to exhaustion of the count parameter. */ bool -PortalRun(Portal portal, long count, bool isTopLevel, +PortalRun(Portal portal, long count, bool isTopLevel, bool run_once, DestReceiver *dest, DestReceiver *altdest, char *completionTag) { @@ -712,6 +715,10 @@ PortalRun(Portal portal, long count, bool isTopLevel, */ MarkPortalActive(portal); + /* Set run_once flag. Shouldn't be clear if previously set. */ + Assert(!portal->run_once || run_once); + portal->run_once = run_once; + /* * Set up global portal context pointers. * @@ -918,7 +925,8 @@ PortalRunSelect(Portal portal, else { PushActiveSnapshot(queryDesc->snapshot); - ExecutorRun(queryDesc, direction, (uint64) count); + ExecutorRun(queryDesc, direction, (uint64) count, + portal->run_once); nprocessed = queryDesc->estate->es_processed; PopActiveSnapshot(); } @@ -957,7 +965,8 @@ PortalRunSelect(Portal portal, else { PushActiveSnapshot(queryDesc->snapshot); - ExecutorRun(queryDesc, direction, (uint64) count); + ExecutorRun(queryDesc, direction, (uint64) count, + portal->run_once); nprocessed = queryDesc->estate->es_processed; PopActiveSnapshot(); } @@ -1394,6 +1403,9 @@ PortalRunFetch(Portal portal, */ MarkPortalActive(portal); + /* If supporting FETCH, portal can't be run-once. */ + Assert(!portal->run_once); + /* * Set up global portal context pointers. */ |