Re: counting algorithm for incremental matview maintenance

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: counting algorithm for incremental matview maintenance
Date: 2013-05-17 19:53:26
Message-ID: CAGTBQpaSmDNM1jd1wJkiTRdhjJzmJYh4EBeCem_a-6mJSvmYFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 17, 2013 at 4:25 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
>> (3) The count algorithm must be implemented in a way that understands
>> MVCC internals: Reading the base tables must be done using a technique
>> that reads all rows (i.e., also the ones not visible to the current
>> transaction), and the xmin/xmax/etc of the updated rows in the matview
>> must be set in a smart way, so as to yield visibility results that
>> correspond to the visibility of the “originating” rows in the base
>> tables. Calculation of the matview deltas (especially the part where
>> the base tables are inspected for joining rows) must in this case
>> probably be done in a serialized manner.
>
> I will look at this option some more, but on the face of it, I'm
> not quite following how it would work; and it sounds invasive and
> fragile.

I don't believe it would be that problematic if deltas:

1 - contains all changes, matching join conditions or not, that could
potentially alter the matview. This includes the example's alterations
since the columns being altered were part of the matview's definition,
but it would not cover updates to columns that were not part of the
definition (ie: not involved in the join or the selected rows).
2 - each update is marked with its xid

Then, "serialization" can be achieved by only applying committed xids,
discarding rolled back xids, and evaluating join satisfaction only
during the updates, and not during delta logging.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nicolas Barbier 2013-05-17 20:33:06 Re: counting algorithm for incremental matview maintenance
Previous Message Liming Hu 2013-05-17 19:39:22 Re: request a new feature in fuzzystrmatch