Re: record identical operator - Mailing list pgsql-hackers

* Kevin Grittner (kgrittn@ymail.com) wrote:
> Unless we can tell whether there are any differences between two
> versions of a row, we can't accurately generate the delta to drive
> the incremental maintenance.

This is predicated on the assumption that you simply generate the new
view and then try to figure out what to go update.  I'm trying to
explain that using that methodology is what landed us in this situation
to begin with.

>   The initial thread discussing how
> incremental maintenance would be done is here:

My apologies for not paying quite as close attention to that thread as I
should have.

> I think it is fairly obvious that REFRESH should REgenerate a FRESH
> copy of the data, versus incremental maintenance -- which attempts
> to keep the matview up-to-date without regenerating the full set of
> data.

Having 'REFRESH' regenerate a fresh copy of the data makes sense to me,
and is what we have now, no?  The only issue there is that it takes out
a big lock, which I appreciate that you're trying to get rid of.

>   Whenever there is logical replication (and materialized
> views are, conceptually, one form of that -- within the database) I
> feel it is important to be able to correct any possible "drift".
> With matviews, I see the way to do that as the REFRESH command, and
> I feel that it is important to be able to do that in a way that can
> run concurrently with readers of the matview -- without blocking
> them or being blocked by them.

Of course.

> Discussion of incremental maintenance really belongs on a different
> thread. 

I'm really getting tired of everyone saying "this is the only way to do
it" (or perhaps "well, this is already committed, therefore it must be
what we're gonna do") when a) we're already planning to rip this out
and change it, or so I thought, and b) we're trying to make promises we
can't keep with this approach.

> Since I have gone to the trouble to read a lot of papers
> on the topic, and select one that I think is a good basis for our
> implementation, I hope everyone will frame discussion in terms of
> either:
>   -  how best to implement the techniques from that paper, or
>   -  why some other paper presents a better technique.

My recollection from the hackers meeting is that I'm trying to simply
paraphrase what you had said was in the paper wrt keeping track of what
rows are changed underneath and using that as a basis to implement the
changes necessary in the view.  Does the paper you're referring to
describe rerunning the whole query and then trying to figure out what's
been changed..?  That's really what I'm having trouble understanding
why anyone would want to implement.  I'll try and find time to hunt down
the threads and papers on it, but I really could have sworn this was
gone over at the hacker meeting- and it made a lot of sense to me, then.

> I really didn't expect to have to burn so much time
> and energy arguing over whether a REFRESH should leave the matview
> accurately containing the results of the matview's query.

I appreciate you bringing me up to speed on where things actually are
here- again, sorry for not realizing the direction that this was going
in earlier; it really didn't even occur to me that it would have gone
down this road.  I, also, didn't expect to spend so much time on this.

> >> We can argue about how it should be named

Really, I'm back to trying to figure out why we want to go down this
road at all.

> >> and whether it should be documented
>
> I thought we had a consensus to document both the existing record
> comparison operators and these new ones, and I'm fine with that.

If it gets added, it certainly should be documented, and heavily
caveated.
Thanks,
    Stephen