Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions |
Дата | |
Msg-id | CAFiTN-vY3fwoiTCQ2A0MusddPSnCu4DOYoE49+1knAqnaSUsMQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
|
Список | 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
В списке pgsql-hackers по дате отправления: