On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar <[email protected]> wrote: > On Tue, Mar 21, 2017 at 3:36 PM, Rafia Sabih > <[email protected]> wrote: >> On Wed, Mar 15, 2017 at 8:55 PM, Robert Haas <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
