On Wed, Jun 7, 2017 at 4:48 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> Is there anything about that semantics that is incompatible with the > incremental matview use case? Nothing incompatible at all. If we had separate "new" tables for UPDATE and DELETE we would logically need to do a "counting"-style UNION of them just like we will want to do with the OLD (with a count of -1) and NEW (with a count of 1) to get to a delta now. So keeping them separate would be marginally more work for incremental matview, but not a big deal. > For example, are the "counting" and > "DRed" algorithms you've proposed (for non-recursive and recursive > views) driven entirely by deletions and insertions, so that updates > look like deletes followed by inserts anyway? Counting is best done from a "delta" relation which has old and new combined with opposite counts. I'm sure that will be fine with DRed, too. > If so, I think our > current treatment of ON CONFLICT DO UPDATE should be fine: you can't > tell whether the tuples in the new table result from insert or update > without also consulting the old table, but if the algorithm treats all > tuples in the old table as deletes (even though in this case they > result from updates) and all tuples in the new table as inserts (even > though in this case *some* of them result from updates) anyway then I > don't think it matters. I don't think so, either. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
