Re: Parallel execution and prepared statements
От | Amit Kapila |
---|---|
Тема | Re: Parallel execution and prepared statements |
Дата | |
Msg-id | CAA4eK1Kr6EWnJNVZEK5NxmUjPveRpTEHiJTn5N4mymuR8h_GLQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel execution and prepared statements (Tobias Bussmann <t.bussmann@gmx.net>) |
Ответы |
Re: Parallel execution and prepared statements
Re: Parallel execution and prepared statements Re: Parallel execution and prepared statements |
Список | pgsql-hackers |
On Wed, Nov 16, 2016 at 2:27 AM, Tobias Bussmann <t.bussmann@gmx.net> wrote: > As the patch in [1] targeting the execution of the plan in ExecutePlan depending on the destination was declined, I hackedaround a bit to find another way to use parallel mode with SQL prepared statements while disabling the parallel executionin case of an non read-only execution. For this I used the already present test for an existing intoClause in ExecuteQueryto set the parallelModeNeeded flag of the prepared statement. This results in a non parallel execution of theparallel plan, as we see with a non-zero fetch count used with the extended query protocol. Despite this patch seem towork 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
В списке pgsql-hackers по дате отправления: