On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger <hornschnor...@gmail.com> wrote:
>> On Jul 3, 2017, at 10:25 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>>> On 30 June 2017 at 05:14, Amit Kapila <amit.kapil...@gmail.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
> ...
> 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?

I don't think it is just a matter of hacking grammar, internally we
are using cursor fetch to fetch the rows and there we are passing some
fixed number of rows to fetch which again is a killer to invoke the
parallel query.

>  And if exception handling is a problem in the loop, are exceptions
> somehow not a problem in other parallel queries?

I don't see exceptions as a blocking factor to choose any parallel
query inside PL.  However, if you have something in mind, feel free to
share with some example?

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to