On 2013-03-07 09:55:39 -0800, Kevin Grittner wrote:
> Andres Freund <andres@2ndquadrant.com> wrote:
>
> > if I understand things correctly REFRESH MATERIALIZED VIEW locks
> > the materialized view with an AcessExclusiveLock even if the view
> > already contains data.
>
> Yeah. At the time I had to make a decision on that, REINDEX
> CONCURRENTLY did not seem reliable with a weaker lock, and REFRESH
> MATERIALIZED VIEW has to rebuild indexes (among other things). If
> we have all the issues sorted out with REINDEX CONCURRENTLY then
> the same techniques will probably apply to RMV without too much
> difficulty. It's a bit late to think about that for 9.3, though.
I don't think that REFRESH MATERIALIZED VIEW has to deal with the same
problems that REINDEX CONCURRENTLY has - after all, there won't be any
DML coming in while its running. That should get rid of the REINDEX
CONCURRENTLY problems.
There doesn't seem to be any need to use the far more expensive REINDEX
CONCURRENLTY style computation of indexes which has to scan the heap
multiple times et al. They just should be built ontop of new matview
relation which is essentially read only.
> > I am pretty sure that will - understandably - confuse users, so I
> > vote for at least including a note about that in the docs.
>
> Will see about working that in.
Cool.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
