|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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.
|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|