On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas <robertmh...@gmail.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/
