On T, 2005-05-17 at 10:56 -0500, Jim C. Nasby wrote:

> Second, the most efficient way to update mviews is to track
> transactions
> against the table(s) that an mview is built on. Of course, this can be
> done via triggers and a queuing mechanism. AFAIK this is what Slony
> does. But such a mechanism actually duplicates what the WAL does, and
> in
> the process, produces much more work for the database, since the data
> logged by the triggers has to be stored in it's own table, which
> generates additional WAL, and then has to be removed some time later,
> generating yet more WAL and the need to vacuum. ISTM that it would be
> a win to be able to pull info out of the WAL directly.
> 
> So I think there's two issues here. One: mview updates will require
> essentially the same mechanism that Slony does, so we should try to use
> one set of code across both projects.

Well, I'm actually using Slony1 + insert rule on target side to have a
"MView" of daily xxx counts that is kept up-to-date in near-real time.

Using slony 1.1s new "statement-shipping" (instead of applying the
captured changes to slave, they are written to text files as SQL and
then this SQL can be applied later) this could also be used as a
delayed/patch-mode MView.

To get most of basic MView functionality from slony in a somewhat
cleaner way would require only small adjustments to some of slony's
commands (EXECUTE SCRIPT should be directed, not try to execute it on
all slanes, an easy way to preserve RULES (in addition to TRIGGERS)
should be there, ...).

-- 
Hannu Krosing <hannu at skype.net>