From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | "'Kevin Grittner'" <kgrittn(at)ymail(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: counting algorithm for incremental matview maintenance |
Date: | 2013-05-17 12:02:37 |
Message-ID: | 008501ce52f6$6cd1bc00$46753400$@kapila@huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wednesday, May 15, 2013 1:22 AM Kevin Grittner wrote:
Good explanation for understanding the initial concept of incremental update
of matviews.
> The original and modified versions of the relations (tables or
> other matviews) which define a matview must be available to
> calculate the matview deltas, so the snapshot information for this
> must be available and registered until the matview delta has been
> calculated. They can be released once the delta has been
> established and before it has been applied to the matview.
Here by modified versions of the relations, do you mean to say delta
relations for recording changes.
Could you elaborate a bit about snapshot information, is this snapshot is
for delta relation, when will it acquire snapshot information to
Update matviews?
> Initial
> milestones in this development will focus on "eager" maintenance,
> so this will not initially be a big issue, but will become more
> important as we work on making more of the work asynchronous, so
> that the foreground query is not held up maintaining data which is
> allowed to be a little stale. This seems not entirely unrelated to
> background worker processes and snapshot sharing.
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-05-17 12:06:45 | Re: counting algorithm for incremental matview maintenance |
Previous Message | Heikki Linnakangas | 2013-05-17 11:30:46 | Re: Full (special) logs for specified users/hosts/etc |