Re: Enabling parallelism for queries coming from SQL or other PL functions
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Rafia Sabih <rafia.sabih@enterprisedb.com>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-02-23T15:50:04Z
Lists: pgsql-hackers
On Thu, Feb 23, 2017 at 8:58 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > Few more comments. > 1.I don't see any check in the code which will prevent the parallel > execution of the query inside a function if its called from a DML > statement. > e.g. If we use a function in the update statement's which has the > select statement. Having said that, I am thinking do we really need to block such cases? It just looks fine to me that an update statement calls a function (in targetlist or condition), which launches a bunch of workers for the internal query inside PL; finishes the work and shutdown them, only after this, the update will change any record. So basically I want to make a point that between the worker launch and shutdown there is no change in the database state. Any other opinion on this? -- Regards, Dilip Kumar 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