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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select
Дата
Msg-id 13212E6F-9446-4EFA-87A2-EA308EE0281B@gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Request more documentation for incompatibility ofparallelism and plpgsql exec_run_select  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Request more documentation for incompatibility ofparallelism and plpgsql exec_run_select  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [HACKERS] Request more documentation for incompatibility ofparallelism and plpgsql exec_run_select  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
> On Jul 3, 2017, at 10:25 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 
> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 30 June 2017 at 05:14, Amit Kapila <amit.kapila16@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

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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Error while copying a large file in pg_rewind
Следующее
От: AP
Дата:
Сообщение: Re: [HACKERS] pgsql 10: hash indexes testing