Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE statement in a PL/pgsql block. As it turns out, the analysis that led to this decision was totally wrong-headed, because the plan will always be executed using SPI_cursor_fetch(portal, true, 50), which will cause ExecutePlan() to get invoked with a count of 50, which will cause it to run the parallel plan serially, without workers. Therefore, passing CURSOR_OPT_PARALLEL_OK is a bad idea here; all it can do is cause us to pick a parallel plan that's slow when executed serially instead of the best serial plan.
The attached patch fixes it. I plan to commit this and back-patch it to 9.6, barring objections or better ideas. I previously remarked on this in http://postgr.es/m/ca+tgmobxehvhbjtwdupzm9bvslitj-kshxqj2um5gpdze9f...@mail.gmail.com but I wasn't quite so clear what the whole picture was in that email as I am now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
no-parallel-return-query.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
