From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enabling parallelism for queries coming from SQL or other PL functions |
Date: | 2017-02-23 15:50:04 |
Message-ID: | CAFiTN-vY3fwoiTCQ2A0MusddPSnCu4DOYoE49+1knAqnaSUsMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 23, 2017 at 8:58 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2017-02-23 15:51:46 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Stephen Frost | 2017-02-23 15:36:37 | Re: pg_upgrade loses security lables and COMMENTs on blobs |