Here's a draft patch showing the sort of thing I have in mind. I think it needs more work, but it gives you the idea, I hope. This is loosely based on your pl_parallel_exec_support_v1.patch, but what I've done here is added some flags that carry the information about whether there will be only one or maybe more than one call to ExecutorRun to a bunch of relevant places.
I think this might have the effect of disabling parallel query in some cases where PL/pgsql currently allows it, and I think that may be necessary. (We may need to back-patch a different fix into 9.6.)
I wanted to clarify a few things here, I noticed that call of ExecutorRun in postquel_getnext() uses !es->lazyEval as execute_once, this is confusing, as it is true even in cases when a simple query like "select count(*) from t" is used in a sql function. Hence, restricting parallelism for cases when it shouldn't. It seems to me that es->lazyEval is not set properly or it should not be true for simple select statements. I found that in the definition of execution_state
boollazyEval;/* true if should fetch one row at a time */
and in init_execution_state, there is a comment saying,
* Mark the last canSetTag query as delivering the function result; then,
* if it is a plain SELECT, mark it for lazy evaluation. If it's not a
* SELECT we must always run it to completion.
I find these two things contradictory to each other. So, is this point missed or is there some deep reasoning behind that?
