On Wed, Nov 16, 2016 at 7:10 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > 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?
Typo. /forc_parallel_mode/force_parallel_mode -- 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
