Robert Haas wrote:
> On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Robert Haas wrote:
>>> 2010/4/10 Andrew Dunstan <andrew@dunslane.net>:
>>>> Heikki Linnakangas wrote:
>>>>> 1. Keep the materialized view up-to-date when the base tables change.
>>>>> This can be further divided into many steps, you can begin by supporting
>>>>> automatic updates only on very simple views with e.g a single table and
>>>>> a where clause. Then extend that to support joins, aggregates,
>>>>> subqueries etc. Keeping it really limited, you could even require the
>>>>> user to write the required triggers himself.
>>>> That last bit doesn't strike me as much of an advance. Isn't the whole point
>>>> of this to automate it? Creating greedy materialized views is usually not
>>>> terribly difficult now, but you do have to write the triggers.
>>> Yeah, I agree.
>> It doesn't accomplish anything interesting on its own. But if you do the
>> planner changes to automatically use the materialized view to satisfy
>> queries (item 2. in my previous email), it's useful.
>
> But you can't do that with a snapshot view, only a continuous updated one.
A materialized view with manually-defined triggers to keep it up-to-date
is a continuously updated one.
Other DBMSs allow that with snapshot views too, you just don't get
totally up-to-date results, but I not sure we want to go there.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
