Re: Materialized views WIP patch

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Kevin Grittner <kgrittn(at)mail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Materialized views WIP patch
Date: 2012-11-16 15:40:51
Message-ID: CAHyXU0zgufXskD71kfRr1C_FHO8C4dFCrcbyArWxKLBpqDW9hQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 16, 2012 at 7:13 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> The documentation says that a materialized view is basically a
>> create-table-as-select except that it remembers the query. Would you say
>> that there is a compelling use case for this alone, or is this a
>> building block for more sophisticated materialized view support (e.g.
>> eager updating) later?
>
> The implementation of the re-LOAD'ing command makes it already
> worthwile. Bonus point if locking is limited to when the new content is
> all computer and ready, but even without that, I want to have it. ;)

Seconded. Background lock free refresh of materialization table would
be wonderful. But moving dependency between source and materialized
table out of plpgsql function and into defined schema justifies
feature on its own merits.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-11-16 15:42:01 Re: gset updated patch
Previous Message Kevin Grittner 2012-11-16 15:36:38 Re: Materialized views WIP patch