Re: Enabling parallelism for queries coming from SQL or other PL functions

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(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 06:00:40
Message-ID: CAFiTN-vLm8yJpqgM4tygVZxPCiJNEBh+XpbxYT8X1g9X-AKxTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 24, 2017 at 10:06 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2017-02-24 06:13:01 utility commands benefiting from parallel plan
Previous Message Venkata B Nagothi 2017-02-24 05:13:45 Re: Range Partitioning behaviour - query