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-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

In response to

Responses

Browse pgsql-hackers by date

  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