| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Steve Singer <steve(at)ssinger(dot)info>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: record identical operator |
| Date: | 2013-09-19 12:41:39 |
| Message-ID: | 1379594499.75672.YahooMailNeo@web162905.mail.bf1.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)2ndQuadrant(dot)com> wrote:
> the patch solves the general problem of "when the table changes,
> refresh"
>
> After saying it like this, the problem could also be solved by
> including xmin(s) for rows from underlying table(s)in the
> matview.
>
> Would this be a better approach ?
Now you're moving from REFRESH territory into incremental
maintenance. There have been a very large number of papers written
on that topic, I have reviewed the literature, and I have picked a
technique which looks like it will be fast and reliable -- based on
relational algebra. Let's save discussion of alternatives such as
you're suggesting here, for when I get past the easy stuff ... like
just refreshing a view so that the new contents are the same as
what you would see if you re-ran the query defining the matview.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-09-19 12:48:01 | Re: FW: REVIEW: Allow formatting in log_line_prefix |
| Previous Message | Andres Freund | 2013-09-19 12:40:35 | Re: Freezing without write I/O |