| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | 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 00:35:03 |
| Message-ID: | 1353976503.4992.10.camel@vanquo.pezone.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Kupershmidt | 2012-11-27 02:45:08 | Re: Suggestion for --truncate-tables to pg_restore |
| Previous Message | Tom Lane | 2012-11-27 00:05:13 | Re: Further pg_upgrade analysis for many tables |