On Wed, Mar 22, 2017 at 3:00 AM, Rafia Sabih <rafia.sa...@enterprisedb.com> wrote:
> On Wed, Mar 22, 2017 at 12:55 AM, Robert Haas <robertmh...@gmail.com> > wrote: > > On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar <dilipbal...@gmail.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
