On Tue, Nov 15, 2016 at 3:57 PM, 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.
Yeah, we could do something like this, perhaps not in exactly this way, but I'm not sure it's a good idea to just execute the parallel plan without workers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
