diff options
| author | Robert Haas <rhaas@postgresql.org> | 2017-03-24 12:30:39 -0400 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2017-03-24 12:39:07 -0400 |
| commit | 5674a258fd7e6eb496a4e91b0907077dfa7ee336 (patch) | |
| tree | a05d26666831fd385d31fea1e2d0b3ed2411cf3c /src | |
| parent | 2ed391f95b34bb88b4d092f0a1d68ce3903df375 (diff) | |
| download | postgresql-5674a258fd7e6eb496a4e91b0907077dfa7ee336.tar.gz postgresql-5674a258fd7e6eb496a4e91b0907077dfa7ee336.zip | |
plpgsql: Don't generate parallel plans for RETURN QUERY.
Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel
plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE
statement in a PL/pgsql block, but that's a bad idea because plplgsql
asks the executor for 50 rows at a time. That means that we'll always
be running serially a plan that was intended for parallel execution,
which is not a good idea. Fix by not requesting a parallel plan from
the outset.
Per discussion, back-patch to 9.6. There is a slight risk that, due
to optimizer error, somebody could have a case where the parallel plan
executed serially is actually faster than the supposedly-best serial
plan, but the consensus seems to be that that's not sufficient
justification for leaving 9.6 unpatched.
Discussion: http://postgr.es/m/CA+TgmoZ_ZuH+auEeeWnmtorPsgc_SmP+XWbDsJ+cWvWBSjNwDQ@mail.gmail.com
Discussion: http://postgr.es/m/CA+TgmobXEhvHbJtWDuPZM9bVSLiTj-kShxQJ2uM5GPDze9fRYA@mail.gmail.com
Diffstat (limited to 'src')
| -rw-r--r-- | src/pl/plpgsql/src/pl_exec.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 3a3d9af79fd..76dd369468d 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -2870,7 +2870,7 @@ exec_stmt_return_query(PLpgSQL_execstate *estate, if (stmt->query != NULL) { /* static query */ - exec_run_select(estate, stmt->query, 0, &portal, true); + exec_run_select(estate, stmt->query, 0, &portal, false); } else { @@ -2878,7 +2878,7 @@ exec_stmt_return_query(PLpgSQL_execstate *estate, Assert(stmt->dynquery != NULL); portal = exec_dynquery_with_params(estate, stmt->dynquery, stmt->params, NULL, - CURSOR_OPT_PARALLEL_OK); + 0); } tupmap = convert_tuples_by_position(portal->tupDesc, |