Robert Haas wrote:
I also think that you're underestimating the number of problems that
will have to be solved to get this done. It's going to take some
significant work - both design work and coding work - to figure out
how this should integrate into the rest of the system. (What should
be
Robert Haas wrote:
2010/4/10 Andrew Dunstan and...@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
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
2010/4/10 Andrew Dunstan and...@dunslane.net:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be further divided into
On 11.04.10 20:47 , Robert Haas wrote:
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
2010/4/10 Andrew Dunstanand...@dunslane.net:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables
On Sun, Apr 11, 2010 at 10:13 PM, Florian G. Pflug f...@phlo.org wrote:
If continuous updates prove to be too hard initially, you could instead
update the view on select if it's outdated. Such a materialized view
would be a kind of inter-session cache for subselects.
The hard part would
On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith g...@2ndquadrant.com wrote:
From the rest of your comments, I'm comfortable that you're in sync with the
not necessarily obvious risky spots here I wanted to raise awareness of.
It's unreasonable to expect we'll have exactly the same priorities
Robert Haas wrote:
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
2010/4/10 Andrew Dunstan and...@dunslane.net:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be
