Re: REFRESH MATERIALIZED VIEW locklevel - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: REFRESH MATERIALIZED VIEW locklevel
Date
Msg-id 513A271E.1000000@agliodbs.com
Whole thread Raw
In response to Re: REFRESH MATERIALIZED VIEW locklevel  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: REFRESH MATERIALIZED VIEW locklevel
List pgsql-hackers
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".

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Identity projection
Next
From: Merlin Moncure
Date:
Subject: Re: REFRESH MATERIALIZED VIEW locklevel