From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enabling parallelism for queries coming from SQL or other PL functions |
Date: | 2017-02-24 04:36:33 |
Message-ID: | CAA4eK1JxUNL6i2vrQx1KZ7-P24rc1vUh+uBeAdx4iByzyesPXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 23, 2017 at 8:58 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Thu, Feb 23, 2017 at 12:11 PM, Rafia Sabih
> <rafia(dot)sabih(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-02-24 04:41:09 | Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags |
Previous Message | Simon Riggs | 2017-02-24 04:23:02 | Re: Documentation improvements for partitioning |