Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
Дата
Msg-id CAFiTN-sn6rRd9tVcVSDH3-CvOMLBvhLTcnDTRYrqdr_XmO0=0w@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 Tue, Mar 21, 2017 at 3:36 PM, Rafia Sabih
<rafia.sabih@enterprisedb.com> wrote:
> On Wed, Mar 15, 2017 at 8:55 PM, Robert Haas <robertmhaas@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Michálek
Дата:
Сообщение: Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)