Skip site navigation (1) Skip section navigation (2)

Re: Materialized views WIP patch

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: "Kevin Grittner" <kgrittn(at)mail(dot)com>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Materialized views WIP patch
Date: 2012-11-16 22:12:21
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
"Kevin Grittner" <kgrittn(at)mail(dot)com> writes:
>> UPDATE MATERIALIZED VIEW was problematic?
> Not technically, really, but I saw two reasons that I preferred LOAD MV:
> 1. It seems to me to better convey that the entire contents of the MV
>    will be built from scratch, rather than incrementally adjusted.
> 2. We haven't hashed out the syntax for more aggressive maintenance of
>    an MV, and it seemed like UPDATE MV might be syntax we would want to
>    use for something which updated selected parts of an MV when we do.

Good point, and while I'm in the mood for some grammar input, here's a


I think such wholesale operations make more sense as ALTER statement
than as UPDATE statements.

> It builds a new heap and moves it into place. When the transaction
> running LMV commits, the old heap is deleted. In implementation it is
> closer to CLUSTER or the new VACUUM FULL than TRUNCATE followed by
> creating a new table. This allows all permissions, etc., to stay in
> place.

When you say closer to CLUSTER, do you include the Access Exclusive Lock
that forbids reading the previous version's data while you prepare the
new one? That would be very bad and I wouldn't understand the need to,
in the scope of MATERIALIZED VIEWs which are by definition lagging

If as I think you don't have that limitation in your implementation,
it's awesome and just what I was hoping to read :)

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-11-16 22:13:01
Subject: Re: Materialized views WIP patch
Previous:From: Dimitri FontaineDate: 2012-11-16 22:05:25
Subject: Re: another idea for changing global configuration settings from SQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group