From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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-10 13:18:34 |
Message-ID: | z2p603c8f071004100618t8638ca5dh65111c95cb0cf67f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> The other thing that could be interesting about this would be some scheme
> for lazy refresh that didn't involve re-extracting the whole data set.
One way to do this would be to infer a primary key for the result set
based on the input query. But I think we don't really have the
infrastructure to do this right now, so not really a project for a
beginner.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Gérard Pailloncy | 2010-04-10 14:00:07 | Virtual Private Database |
Previous Message | Andrew Dunstan | 2010-04-10 13:15:25 | Re: GSoC - proposal - Materialized Views in PostgreSQL |