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-25 11:42:25 |
Message-ID: | CAA4eK1J-oqTsL0VUC15ebMGOzdiX4CLEX3NaLZHNFgF64txGJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 24, 2017 at 11:30 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> 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.
>
Sure, but that should only happen if the function is *not* declared as
parallel safe (aka in parallel safe functions, we should not generate
parallel plans).
> So I think we
> may need some check during execution time as well?
>
Right, I also think we need some mechanism where if the user has not
marked the parallel safe functions appropriately, then such executions
should result in error. For example, if parallel-safe function calls
a parallel-unsafe function which contains either write statement or
statement that could generate a parallel plan, then we should not
allow execution of such queries. We already have safeguard checks at
most places like write statements (see heap_update), however, I think
we need a similar check in ExecGather.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-02-25 12:37:48 | Re: Proposal : Parallel Merge Join |
Previous Message | Simon Riggs | 2017-02-25 11:36:20 | Re: Allow pg_dumpall to work without pg_authid |