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:

Reply via email to