From: | Robert Haas <robertmhaas(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 15:35:37 |
Message-ID: | CA+TgmoZGLZ+HT8gA=7L9UkwwnGSf4Sor8o990we58H+hYj+qrQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 15, 2016 at 3:57 PM, 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-11-16 15:40:35 | Re: WIP: About CMake v2 |
Previous Message | Robert Haas | 2016-11-16 15:33:56 | Re: Re: [COMMITTERS] pgsql: Build HTML documentation using XSLT stylesheets by default |