> -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.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@postgresql.org) To make > changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
