Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions |
| Дата | |
| Msg-id | CA+Tgmoate8SvGr=3e76ONdNn_16J7Csv0wd7wGxTrnVryY9drA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions (Rafia Sabih <rafia.sabih@enterprisedb.com>) |
| Ответы |
Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
|
| Список | pgsql-hackers |
On Wed, Mar 22, 2017 at 3:00 AM, Rafia Sabih <rafia.sabih@enterprisedb.com> wrote:
On Wed, Mar 22, 2017 at 12:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar <dilipbalaut@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.
--
В списке pgsql-hackers по дате отправления: