From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | 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 13:13:43 |
Message-ID: | m2fw491yig.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. ;)
I'd bikeshed and prefer the UPDATE MATERIALIZED VIEW nsp.foo; of course.
The alternative is creating a view, a matching table and a stored
procedure that will implement the rebuilding, for each mat view you want
to have. So that's already a big step forward in my eyes.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-11-16 13:17:34 | Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database) |
Previous Message | Amit Kapila | 2012-11-16 11:40:03 | Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown |