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-vLm8yJpqgM4tygVZxPCiJNEBh+XpbxYT8X1g9X-AKxTQ@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
|
Список | pgsql-hackers |
On Fri, Feb 24, 2017 at 10:06 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > 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); > } Ok, I see. But, the problem with PL functions is that plan might have already generated in previous execution of the function and during that time outer query might not be running in parallel. So I think we may need some check during execution time as well? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: