Re: Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Request more documentation for incompatibility of parallelism and plpgsql exec_run_select
Date: 2017-07-05 04:14:04
Message-ID: 13212E6F-9446-4EFA-87A2-EA308EE0281B@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Jul 3, 2017, at 10:25 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 30 June 2017 at 05:14, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>>> This is explained in section 15.2 [1], refer below para:
>>> "The query might be suspended during execution. In any situation in
>>> which the system thinks that partial or incremental execution might
>>> occur, no parallel plan is generated. For example, a cursor created
>>> using DECLARE CURSOR will never use a parallel plan. Similarly, a
>>> PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
>>> use a parallel plan, because the parallel query system is unable to
>>> verify that the code in the loop is safe to execute while parallel
>>> query is active."
>>
>> Can you explain "unable to verify that the code in the loop is safe to
>> execute while parallel query is active". Surely we aren't pushing code
>> in the loop into the actual query, so the safety of command in the FOR
>> loop has nothing to do with the parallel safety of the query.
>>
>> Please give an example of something that would be unsafe? Is that
>> documented anywhere, README etc?
>>
>> FOR x IN query LOOP .. END LOOP
>> seems like a case that would be just fine, since we're going to loop
>> thru every row or break early.
>>
>
> It is not fine because we don't support partial execution support. In
> above case, if the loop breaks, we can't break parallel query
> execution. Now, I don't think it will impossible to support the same,
> but as of now, parallel subsystem doesn't have such a support.

I can understand this, but wonder if I could use something like

FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
...
END LOOP;

if I hacked the grammar up a bit. Would the problem go away, or would
I still have problems when exceptions beyond my control get thrown inside
the loop? And if exception handling is a problem in the loop, are exceptions
somehow not a problem in other parallel queries?

Obviously I mean that syntax above in jest, but the question is in ernest.

Thanks,

mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message AP 2017-07-05 04:23:23 Re: pgsql 10: hash indexes testing
Previous Message Michael Paquier 2017-07-05 04:05:17 Re: Error while copying a large file in pg_rewind