Re: [HACKERS] REFRESH MATERIALIZED VIEW locklevel

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, PostgreSQL Advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] REFRESH MATERIALIZED VIEW locklevel
Date: 2013-03-08 17:59:58
Message-ID: 513A271E.1000000@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy 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

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Merlin Moncure 2013-03-08 18:09:23 Re: REFRESH MATERIALIZED VIEW locklevel
Previous Message Nicolas Barbier 2013-03-08 11:24:05 Re: REFRESH MATERIALIZED VIEW locklevel

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-03-08 18:09:23 Re: REFRESH MATERIALIZED VIEW locklevel
Previous Message Heikki Linnakangas 2013-03-08 17:51:42 Re: Identity projection