On Fri, Feb 24, 2017 at 11:43 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > Here I attached an implementation patch that allows > utility statements that have queries underneath such as > CREATE TABLE AS, CREATE MATERIALIZED VIEW > and REFRESH commands to benefit from parallel plan. > > These write operations not performed concurrently by the > parallel workers, but the underlying query that is used by > these operations are eligible for parallel plans. > > Currently the write operations are implemented for the > tuple dest types DestIntoRel and DestTransientRel. > > Currently I am evaluating other write operations that can > benefit with parallelism without side effects in enabling them.
The Idea looks good to me. Since we are already modifying heap_prepare_insert, I am thinking that we can as well enable queries like "insert into .. select from .." with minor modification? - * For now, parallel operations are required to be strictly read-only. - * Unlike heap_update() and heap_delete(), an insert should never create a - * combo CID, so it might be possible to relax this restriction, but not - * without more thought and testing. + * For now, parallel operations are required to be strictly read-only in + * parallel worker. This statement is still not true, we can not do heap_update in the leader even though worker are doing the read-only operation (update with select). We can change the comments such that it appears more specific to insert I think. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers