From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | "'Kevin Grittner'" <kgrittn(at)ymail(dot)com>, "'Josh Berkus'" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: counting algorithm for incremental matview maintenance |
Date: | 2013-05-17 12:06:45 |
Message-ID: | 008601ce52f7$00bd0370$02370a50$@kapila@huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday, May 16, 2013 7:02 PM Kevin Grittner wrote:
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Let's say there is a table and matview like this:
> create table foo (fooid int primary key, val int not null);
> create materialized view bar as select distinct val from foo;
> Let's say there are millions of rows in both, and that we have
> flagged the view for incremental maintenance. (Syntax omitted to
> avoid distracting bikeshedding on that when the point is the
> algorithm.)
> Now, someone runs this:
> update foo set val = val + 1 where fooid between 1 and 10;
> What will happen is this:
> Since foo will be flagged as a relation which is referenced by an
> incrementally maintained matview, a delta relation will be
> materialized for this update, which will contain the net change to
> the underlying table in the count_t system column.
How and when will it clear old rows of delta relation especially when there
are more than one matview is defined on table and how will it maintain from
where to start
second time refresh from this delta relation to matview.
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-05-17 13:29:29 | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Previous Message | Amit Kapila | 2013-05-17 12:02:37 | Re: counting algorithm for incremental matview maintenance |