From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pavelbaros <baros(dot)p(at)seznam(dot)cz>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GSoC - proposal - Materialized Views in PostgreSQL |
Date: | 2010-04-11 18:47:36 |
Message-ID: | u2k603c8f071004111147g3e66e561o1fdaa60e526afe3d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Robert Haas wrote:
>> 2010/4/10 Andrew Dunstan <andrew(at)dunslane(dot)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.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2010-04-12 02:13:34 | Re: GSoC - proposal - Materialized Views in PostgreSQL |
Previous Message | Peter Eisentraut | 2010-04-11 16:48:34 | Re: psql's \d display of unique index vs. constraint |