Re: Parallel execution and prepared statements

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Parallel execution and prepared statements
Date: 2016-11-16 13:40:21
Message-ID: CAA4eK1Kr6EWnJNVZEK5NxmUjPveRpTEHiJTn5N4mymuR8h_GLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 16, 2016 at 2:27 AM, Tobias Bussmann <t(dot)bussmann(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-11-16 13:41:46 Re: Parallel execution and prepared statements
Previous Message Kevin Grittner 2016-11-16 13:39:11 Re: Snapshot too old logging