Re: utility commands benefiting from parallel plan

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: utility commands benefiting from parallel plan
Date: 2017-10-11 07:30:49
Message-ID: CAJrrPGd8qJhjVhAOiy85Q3mGxMewVusNMzM+c-LUo_jQR8i7Pw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 6, 2017 at 2:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Sep 15, 2017 at 2:22 AM, Haribabu Kommi
> <kommi(dot)haribabu(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2017-10-11 08:19:56 Re: show precise repos version for dev builds?
Previous Message tushar 2017-10-11 07:12:18 Re: parallelize queries containing initplans