plpgsql: Don't generate parallel plans for RETURN QUERY.
Commit 7aea8e4f2d
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
This commit is contained in:
parent
857ee8e391
commit
f120b614e0
|
@ -3023,7 +3023,7 @@ exec_stmt_return_query(PLpgSQL_execstate *estate,
|
||||||
if (stmt->query != NULL)
|
if (stmt->query != NULL)
|
||||||
{
|
{
|
||||||
/* static query */
|
/* static query */
|
||||||
exec_run_select(estate, stmt->query, 0, &portal, true);
|
exec_run_select(estate, stmt->query, 0, &portal, false);
|
||||||
}
|
}
|
||||||
else
|
else
|
||||||
{
|
{
|
||||||
|
@ -3031,7 +3031,7 @@ exec_stmt_return_query(PLpgSQL_execstate *estate,
|
||||||
Assert(stmt->dynquery != NULL);
|
Assert(stmt->dynquery != NULL);
|
||||||
portal = exec_dynquery_with_params(estate, stmt->dynquery,
|
portal = exec_dynquery_with_params(estate, stmt->dynquery,
|
||||||
stmt->params, NULL,
|
stmt->params, NULL,
|
||||||
CURSOR_OPT_PARALLEL_OK);
|
0);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Use eval_mcontext for tuple conversion work */
|
/* Use eval_mcontext for tuple conversion work */
|
||||||
|
|
Loading…
Reference in New Issue