Re: Enabling parallelism for queries coming from SQL or other PL functions

On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> 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
bool lazyEval; /* 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?

--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/