Hi,
On 2013-03-07 15:21:35 -0800, Josh Berkus wrote:
> > This fact imo reduces the usability of the matviews features as it
> > stands atm considerably. I think we should be very careful not to
> > advocate its existance much and document very clearly that its work in
> > progress.
> > Working incrementally is a sensible thing to do, don't get me wrong...
>
> -1 from me.
>
> Postgres is currently full of fairly innocent-looking commands which
> take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT
> takes an accessexclusive lock, but it hasn't stopped people from using
> constraints, and isn't particularly high up on our todo list to fix
> it.
Thats a pretty unconvincing comparison. There isn't any expectation that
ALTER TABLE works without taking exlusive locks from common
implementations and DROP CONSTRAINT only takes a very short time while
refreshing a materialized view possibly take rather long.
> This limitation is in no way crippling for this feature, or even a major
> detraction. I still intend to promote the heck out of this feature.
Thats scaring me. Because the current state of the feature isn't
something that people expect under the term "materialized views" and I
am pretty damn sure people will then remember postgres as trying to
provide a tick-box item without it being really usable in the real
world.
And thats not something I want postgres to be known for.
Note that I *really* think working incrementally on such things is the
way to go and I think its good that this got committed in 9.3. But if
this now gets used prominently in promotion in its current state I think
the conclusion is that working incrementally in postgres isn't the way
to go and that will make it *much* harder to do so in future
releases. Which will slow postgres down.
Greetings,
Andres Freund