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-25 16:17:36 |
Message-ID: | CAFiTN-tT5XfrUHYYdxPd6WNXn-uFji_Mj1+0x-W2z0kX+0+_fQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> 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 basically we want to put a restriction that parallel-safe function
can not use the parallel query? This will work but it seems too
restrictive to me. Because by marking function parallel safe we enable
it to be used with the outer parallel query that is fine. But, that
should not restrict the function from using the parallel query if it's
used with the other outer query which is not having the parallel
plan(or function is executed directly).
>
>> 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.
How about we allow parallel-safe functions to create a parallel plan
but whenever it's used from an unsafe place i.e. already in the
parallel mode we don't allow to launch worker?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-02-25 16:51:48 | Re: btree_gin and btree_gist for enums |
Previous Message | Magnus Hagander | 2017-02-25 15:41:51 | Re: Automatic cleanup of oldest WAL segments with pg_receivexlog |