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
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 |