From f120b614e070aed39586d1443193738a149a90d4 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Fri, 24 Mar 2017 12:30:39 -0400 Subject: [PATCH] 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 --- src/pl/plpgsql/src/pl_exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 49a4e622ff..8e836a8149 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -3023,7 +3023,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 { @@ -3031,7 +3031,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); } /* Use eval_mcontext for tuple conversion work */ -- 2.40.0