Re: REFRESH MATERIALIZED VIEW locklevel

On Fri, Mar 8, 2013 at 11:59 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Andres,
>
> Crossing this over to pgsql-advocacy, because this is really an Advocacy
> discussion.
>
>> The point is that
>> a) refreshing is the only way to update materialized views. There's no
>> incremental support.
>> b) refreshing will take a long time (otherwise you wouldn't have
>> create a materialized view) and you can't use the view during that.
>>
>> Which means for anyone wanting to use matviews in a busy environment you
>> will need to build the new matview separately and then move it into
>> place via renames. With all the issues that brings like needing to
>> recreate dependent views and such.
>
> There's a lot of shops which currently have matviews which are referesed
> daily, during low-activity periods. I consult for several. While
> concurrent refresh will make MVs much more useful for shops with a
> tighter refresh cycle, what Kevin has developed is useful *to me*
> immediately. It allows me to cut dozens to hundreds of lines of
> application code and replace it with a simple declaration and a Refresh
> cron job.
>
>> Sorry, but thats not very useful expect (and there very much so) as a
>> stepping stone for further work.
>
> What you're saying is "MVs aren't useful *to me* in their current state,
> therefore they aren't useful, therefore they're a non-feature." Well,
> the 9.3 version is useful to *me*, and I expect that they will be useful
> to a large number of other people, even if they don't help *you*.
>
> As a parallel feature, 9.2's cascading replication is completely useless
> to me and my clients because streaming-only remastering isn't supported.
> I expressed the opinion that maybe we shouldn't promote cascade rep as
> a major feature until it was; I was outvoted, because it turns out that
> 9.2 cascade rep *is* useful to a large number of people who are willing
> to work around its current limitations.
>
> Further, we get pretty much one and only one chance to promote a new
> major feature, which is when that feature is first introduced.
> Improving the feature in the next version of Postgres is not news, so we
> can't successfully promote it. If we soft-pedal MVs in the 9.3
> announcement, we will not be able to get people excited about them in
> 9.4; they will be "yesterday's news".

+1 on this. they are useful to me as immediately and I work in busy
environments. the formal matview feature is a drop in replace for my
ad hoc implementation of 'drop cache table, replace from view'. I
already have to work around the locking issue anyways -- sure, it
would be great if I didn't have to do that either but I'll take the
huge syntactical convenience alone.

merlin