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+cwvwbsjn...@mail.gmail.com Discussion: http://postgr.es/m/ca+tgmobxehvhbjtwdupzm9bvslitj-kshxqj2um5gpdze9f...@mail.gmail.com Branch ------ REL9_6_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/5674a258fd7e6eb496a4e91b0907077dfa7ee336 Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
