Horton

Re: Parallel execution and prepared statements

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Albe Laurenz <laurenz.albe@wien.gv.at>, "Tobias Bussmann *EXTERN*" <t.bussmann@gmx.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-12-08T02:23:44Z
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.

Attachments

On Wed, Dec 7, 2016 at 12:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 6, 2016 at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Done.
>>
>> The comment seems quite confused now:
>>
>>     * If a tuple count was supplied or data is being written to relation, we
>>     * must force the plan to run without parallelism, because we might exit
>>     * early.
>>
>> Exit early is exactly what we *won't* do if writing to an INTO rel, so
>> I think this will confuse future readers.  I think it should be more like
>>
>>     * If a tuple count was supplied, we must force the plan to run without
>>     * parallelism, because we might exit early.  Also disable parallelism
>>     * when writing into a relation, because [ uh, why exactly? ]
>>
>> Considering that the writing would happen at top level of the executor,
>> and hence in the parent process, it's not actually clear to me why the
>> second restriction is there at all: can't we write tuples to a rel even
>> though they came from a parallel worker?  In any case, the current wording
>> of the comment is a complete fail at explaining this.
>
> Oops.  You're right.  [ uh, why exactly? ] -> no database changes
> whatsoever are allowed while in parallel mode.  (This restriction
> might be lifted someday, but right now we're stuck with it.)
>

Attached patch changes the comment based on above suggestions.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com