On Wed, Nov 16, 2016 at 7:10 PM, Amit Kapila <[email protected]> wrote: > On Wed, Nov 16, 2016 at 2:27 AM, Tobias Bussmann <[email protected]> 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?
Typo. /forc_parallel_mode/force_parallel_mode -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
