Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions |
Дата | |
Msg-id | CAA4eK1JxUNL6i2vrQx1KZ7-P24rc1vUh+uBeAdx4iByzyesPXw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
|
Список | pgsql-hackers |
On Thu, Feb 23, 2017 at 8:58 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > On Thu, Feb 23, 2017 at 12:11 PM, Rafia Sabih > <rafia.sabih@enterprisedb.com> wrote: > > 2. How are you protecting, if the outer select is running in parallel, > then the function called from there should not run anything in > parallel? This may allow worker launching another set of workers. Am > I missing something? > We have a below check in standard_planner() (!IsParallelWorker()) which should prohibit generating parallel plan inside worker, if that is what you are seeing, then we might need a similar check at other places. if ((cursorOptions & CURSOR_OPT_PARALLEL_OK) != 0 && IsUnderPostmaster && dynamic_shared_memory_type != DSM_IMPL_NONE && parse->commandType == CMD_SELECT && !parse->hasModifyingCTE && max_parallel_workers_per_gather > 0 && !IsParallelWorker() && !IsolationIsSerializable()) { /* all the cheap tests pass, so scan the query tree */ glob->maxParallelHazard = max_parallel_hazard(parse); glob->parallelModeOK = (glob->maxParallelHazard != PROPARALLEL_UNSAFE); } -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: