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? >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. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
