On Wed, Nov 16, 2016 at 2:27 AM, Tobias Bussmann <t.bussm...@gmx.net> wrote: > As the patch in [1] targeting the execution of the plan in ExecutePlan > depending on the destination was declined, I hacked around a bit to find > another way to use parallel mode with SQL prepared statements while disabling > the parallel execution in case of an non read-only execution. For this I used > the already present test for an existing intoClause in ExecuteQuery to set > the parallelModeNeeded flag of the prepared statement. This results in a non > parallel execution of the parallel plan, as we see with a non-zero fetch > count used with the extended query protocol. Despite this patch seem to work > in my tests, I'm by no means confident this being a proper way of handling > the situation in question. >
Can you once test by just passing CURSOR_OPT_PARALLEL_OK in PrepareQuery() and run the tests by having forc_parallel_mode=regress? It seems to me that the code in the planner is changed for setting a parallelModeNeeded flag, so it might work as it is. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
