Re: Enabling parallelism for queries coming from SQL or other PL functions
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Rafia Sabih <rafia.sabih@enterprisedb.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-02-26T01:04:23Z
Lists: pgsql-hackers
On Sat, Feb 25, 2017 at 9:47 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila <amit.kapila16@gmail.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). > I think if the user is explicitly marking a function as parallel-safe, then it doesn't make much sense to allow parallel query in such functions as it won't be feasible for the planner (or at least it will be quite expensive) to detect the same. By the way, if the user has any such expectation from a function, then he can mark the function as parallel-restricted or parallel-unsafe. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Improve access to parallel query from procedural languages.
- 61c2e1a95f94 10.0 landed
-
plpgsql: Don't generate parallel plans for RETURN QUERY.
- 5674a258fd7e 9.6.3 landed
- f120b614e070 10.0 landed
-
Allow for parallel execution whenever ExecutorRun() is done only once.
- 691b8d59281b 10.0 landed