Horton

Re: Parallel execution and prepared statements

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tobias Bussmann <t.bussmann@gmx.net>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Albe Laurenz <laurenz.albe@wien.gv.at>
Date: 2016-11-16T13:41:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Enable parallelism for prepared statements and extended query protocol.

On Wed, Nov 16, 2016 at 7:10 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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 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