Re: record identical operator

Robert, all,

Skipping out on much of the side-discussion to try and drive at the
heart of this..

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> I would suggest that you read the referenced papers for details as to
> how the algorithm works. To make a long story short, they do need to
> keep track of what's changed, and how.

I suppose it's good to know that I wasn't completely misunderstanding
the discussion in Ottawa.

> However, that still seems
> largely orthogonal to the present discussion.

It *solves* this issue, from where I'm sitting, without any binary
operators at all.

rows 4, 5, 6 are used to compose matrow 1. When 4, 5, or 6 are updated,
matrow 1 gets updated.

When the update happens, and it *will* happen (there's no question about
"oh, should we actually update this record?"), it's a normal PG update
and all of the values in the row get set to whatever the new values are.

The only reason we've having any of this discussion is because, in the
current implementation, aiui anyway, we're saying "oh, the user wants us
to update the matview, but we have *no clue* what actually changed, so
we're just gonna try and guess.." This is changing that from "we're
gonna try and guess.." to "well, if they aren't *binary identical*,
we'll change them." However, if you're actually tracking what's
changing and rebuilding the rows based on that, there's no question
about binary equality, and you're still only updating the rows that
actually need to be updated.

Thanks,

Stephen