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
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 |