On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Tue, Mar 21, 2017 at 3:36 PM, Rafia Sabih > <rafia.sa...@enterprisedb.com> wrote: >> On Wed, Mar 15, 2017 at 8:55 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> Note this: >>> >>> if (completed || !fcache->returnsSet) >>> postquel_end(es); >>> >>> When the SQL function doesn't return a set, then we can allow >>> parallelism even when lazyEval is set, because we'll only call >>> ExecutorStart() once. But my impression is that something like this: > > 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. >>SELECT * FROM blah() LIMIT 3 >> >>...will trigger three separate calls to ExecutorRun(), which is a >>problem if the plan is a parallel plan. > > And you also need to test this case what Robert have mentioned up thread. +1 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
