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

On Wed, Mar 22, 2017 at 3:00 AM, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>
wrote:

> On Wed, Mar 22, 2017 at 12:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> > On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
> wrote:
> >> How about taking the decision of execute_once based on
> >> fcache->returnsSet instead of based on lazyEval?
> >>
> >> change
> >> + ExecutorRun(es->qd, ForwardScanDirection, count, !es->lazyEval);
> >> to
> >> + ExecutorRun(es->qd, ForwardScanDirection, count, !fcache->returnsSet);
> >>
> >> IMHO, Robert have the same thing in mind?
> >
> > Yeah, something like that.
> >
> Done in execute-once-v2.patch
>

So, let's see here. We are safe so long as we're sure that, when
postquel_getnext() returns, postquel_end() will be called next without
iterating the loop in fmgr_sql(). That will definitely be true if
fcache->returnsSet is true. It will also be true if postquel_getnext
returns true, which will be true whenever count == 0, which will be true
whenever es->lazyEval is false.

So couldn't we actually make this test !fcache->returnsSet ||
!es->lazyEval? That would let us allow parallel execution for all
non-set-returning functions, and also for set-returning functions that end
up with es->lazyEval set to false.

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