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

On Thu, Aug 10, 2017 at 6:21 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> 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
> suspended in mid query is simply the caller's problem if the caller does
> not honor the contract.

I understand. My point is: that isn't sufficient to solve the
problem. It's not a question of whether the caller uses all the
tuples, but whether the caller gets to do anything else while the
tuples are being generated, so to make it work, you'd have to first
run the parallel query to completion and buffer all the tuples in
memory and *only then* begin iterating over them and running the
user-supplied code. You can't run the parallel query until it
produces a tuple, then do the code inside the loop, then run it until
the next tuple shows up, etc.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company