Re: utility commands benefiting from parallel plan
Haribabu Kommi <kommi.haribabu@gmail.com>
From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Rafia Sabih <rafia.sabih@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-10-11T07:30:49Z
Lists: pgsql-hackers
On Fri, Oct 6, 2017 at 2:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Sep 15, 2017 at 2:22 AM, Haribabu Kommi > <kommi.haribabu@gmail.com> wrote: > > Thanks for the review. > > I committed this patch with some cosmetic changes. I think the fact > that several people have asked for this indicates that, even without > making some of the more complicated cases work, this has some value. > I am not convinced it is safe in any case other than when the DML > command is both creating and populating the table, so I removed > REFRESH MATERIALIZED VIEW support from the patch and worked over the > documentation and comments to a degree. > > The problem with a case like REFRESH MATERIALIZED VIEW is that there's > nothing to prevent something that gets run in the course of the query > from trying to access the view (and the heavyweight lock won't prevent > that, due to group locking). That's probably a stupid thing to do, > but it can't be allowed to break the world. The other cases are safe > from that particular problem because the table doesn't exist yet. > Thanks for committing the patch. I understand the problem of REFRESH MATERIALIZED VIEW case. Regards, Hari Babu Fujitsu Australia
Commits
-
Allow DML commands that create tables to use parallel query.
- e9baa5e9fa14 11.0 landed