On 09/19/2013 02:41 PM, Kevin Grittner wrote: > Hannu Krosing <ha...@2ndquadrant.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. I'm sure that comparing xmin records would work exactly similar to binary comparisons of records for detecting possible change in 99.999% of real-world cases.
I am also pretty sure it would have its own cans of worms all over again when trying to actually implement this in matviews :) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers