On Fri, May 17, 2013 at 4:25 PM, Kevin Grittner <kgrittn@ymail.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.
