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

  1. Allow DML commands that create tables to use parallel query.