From: | "David Rowley" <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "'Kevin Grittner'" <kgrittn(at)mail(dot)com> |
Cc: | "'Pgsql Hackers'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Materialized views WIP patch |
Date: | 2012-11-27 04:46:39 |
Message-ID: | 000901cdcc5a$33734e10$9a59ea30$@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Peter Eisentraut
> Sent: 27 November 2012 13:35
> To: Kevin Grittner
> Cc: Pgsql Hackers
> Subject: Re: [HACKERS] Materialized views WIP patch
>
> On Mon, 2012-11-26 at 09:46 -0500, Peter Eisentraut wrote:
> > On 11/14/12 9:28 PM, Kevin Grittner wrote:
> > > 17. Since the data viewed in an MV is not up-to-date with the latest
> > > committed transaction,
> >
> > So, the way I understand it, in Oracle terms, this feature is a
> > "snapshot", not a materialized view. Maybe that's what it should be
> > called then.
>
> OK, I take everything back and claim the opposite.
>
> In current Oracle, SNAPSHOT is an obsolete alias for MATERIALIZED VIEW.
> Materialized views have the option of REFRESH ON DEMAND and REFRESH
> ON COMMIT, with the former being the default. So it seems that the syntax
> of what you are proposing is in line with Oracle.
>
> I'm not fond of overloading LOAD as the refresh command. Maybe you could
> go the Oracle route here as well and use a stored procedure. That would also
> allow things like SELECT pg_refresh_mv(oid) FROM ... more easily.
>
>
+1 to this.
I can see a use case where you might want to refresh all MVs that are X number of days/hours old. Rather than having to execute statements for each one. Something like pg_refresh_mv() within a query would allow this.
Pretty exciting work Kevin, I understand what Robert said about feature creep etc and agree 100%, but I'm really looking forward to when we can *one day* have the planner make use of an eager MV to optimise a query!
Regards
David Rowley
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org) To make
> changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2012-11-27 04:48:37 | Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update |
Previous Message | Michael Paquier | 2012-11-27 04:37:05 | Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update |