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+TgmoaOUsfm5uBJR1PJEqB0jme4_2XYUEX838dc=rNLhrmT8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Mon, Feb 27, 2017 at 8:33 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Is there any easy way to find out which way is less expensive?

No.  But that's a separate problem.  I'm just saying we shouldn't
arbitrarily prohibit parallelism for parallel-safe functions.

> Even
> if we find some way or just make a rule that when an outer query uses
> parallelism, then force function call to run serially, how do we
> achieve that I mean in each worker we can ensure that each
> individual statements from a function can run serially (by having a
> check of isparallelworker() in gather node), but having a similar
> check in the master backend is tricky or maybe we don't want to care
> for the same in master backend.  Do you have any suggestions on how to
> make it work?

I don't understand what's wrong with the existing logic in standard_planner().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] DROP FUNCTION of multiple functions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] I propose killing PL/Tcl's "modules" infrastructure