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

2017-08-11 Thread Robert Haas
On Thu, Aug 10, 2017 at 6:21 PM, Mark Dilger wrote: > That misses the point I was making. I was suggesting a syntax where > the caller promises to use all rows without stopping short, and the > database performance problems of having a bunch of parallel workers >

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

2017-08-10 Thread Mark Dilger
> On Aug 10, 2017, at 11:20 AM, Robert Haas wrote: > > On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger wrote: >> 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 >>

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

2017-08-10 Thread Robert Haas
On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger wrote: > 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; Actually, what you'd need is: FOR I TOTALLY PROMISE TO USE ALL ROWS

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

2017-07-05 Thread Mark Dilger
> On Jul 5, 2017, at 5:30 AM, Amit Kapila wrote: > > On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote: >> >>> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: >>> >>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs

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

2017-07-05 Thread Amit Kapila
On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote: > >> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: >> >> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote: >>> On 30 June 2017 at 05:14, Amit Kapila

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

2017-07-04 Thread Mark Dilger
> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: > > On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote: >> On 30 June 2017 at 05:14, Amit Kapila wrote: >> >>> This is explained in section 15.2 [1], refer below para:

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

2017-07-03 Thread Amit Kapila
On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote: > On 30 June 2017 at 05:14, Amit Kapila 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

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

2017-07-03 Thread Simon Riggs
On 30 June 2017 at 05:14, Amit Kapila 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

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

2017-07-03 Thread Robert Haas
On Fri, Jun 30, 2017 at 9:32 AM, Mark Dilger wrote: >> On Jun 29, 2017, at 8:55 PM, Mark Dilger wrote: >> Changing myfunc to create a temporary table, to execute the sql to populate >> that temporary table, and to then loop through the temporary

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

2017-06-30 Thread Mark Dilger
> On Jun 29, 2017, at 8:55 PM, Mark Dilger wrote: > > > Changing myfunc to create a temporary table, to execute the sql to populate > that temporary table, and to then loop through the temporary table's rows > fixes the problem. For the real-world example where I hit

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

2017-06-29 Thread Mark Dilger
> On Jun 29, 2017, at 9:14 PM, Amit Kapila wrote: > > On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote: >> Hackers, >> >> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not >> allow a parallel plan if a portal will be

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

2017-06-29 Thread Amit Kapila
On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote: > Hackers, > > In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not > allow a parallel plan if a portal will be returned. This has the practical > consequence that a common coding practice (at least

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

2017-06-29 Thread Mark Dilger
Hackers, In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not allow a parallel plan if a portal will be returned. This has the practical consequence that a common coding practice (at least for me) of doing something like: create function myfunc(arg1 text, arg2 text) returns