* Kevin Grittner (kgrittn@ymail.com) wrote:
> The only thing the paper says on the topic is that any incremental
> maintenance scheme is a heuristic. There will always be cases when
> it would be faster and less resource-intensive to regenerate the
> data from the defining query. There is at least an implication
> that a good implementation will try to identify when it is in such
> a situation, and ignore the whole incremental maintenance approach
> in favor of what we are doing with REFRESH. The example they give
> is if there is an unqualified DELETE of every row in a table which
> is part of an inner join generating the result, that it would
> almost be faster to to generate the (empty) result set than to run
> their algorithm to determine that all the rows need to be deleted.
> One reason for having a REFRESH that re-runs the query like this is
> that it *is* a recommended "escape hatch" when a mass operation
> makes the incremental calculations too expensive.
I was just chatting about this with a coworker and we see a *lot* of
cases where an unqualified DELETE and then INSERT would be perfectly
acceptable over the existing heavy lock that's taken out. We're already
doing that in a lot of places because it's actually pretty cheap and the
"view" results aren't all that big. It's also completely defensible and
doesn't require any new operators.
> > and heavily caveated.
>
> I'm not sure what caveats would be needed. It seems to me that a
> clear description of what it does would suffice. Like all the
> other non-default opclasses in core, it will be non-default because
> it is less frequently useful.
"This will claim things are different, even when they aren't different
when cast to text, or possibly even when extracted in binary mode,
ensure this is really what you want" is a pretty big caveat, imv.
Thanks,
Stephen