On Thu, Aug 10, 2017 at 6:21 PM, Mark Dilger <hornschnor...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
