Stephen Frost <sfrost@snowman.net> wrote:
> If we were consistently copying and updating the value based on
> some external knowledge that the value has changed (similar to
> how slony works w/ triggers that dump change sets into a table-
> it doesn't consider "has any value on this row changed?"; the
> user did an update, presumably for some purpose, therefore the
> change gets recorded and propagated), I'd be perfectly happy.
That is the equivalent of the incremental maintenance feature which
won't be coming until after REFRESH has settled down. REFRESH is
more like the slony initial population of a table. REFRESH
CONCURRENTLY is a way of doing that which allows users to continue
to read from the matview without blocking or interruption while the
REFRESH is running; I think it would be a bug if that could
generate different results from a non-CONCURRENT REFRESH.
Wanting incremental maintenance (which we all want) is no reason to
block an earlier implementation of REFRESH CONCURRENTLY which is
not, and does not use, incremental maintenance.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company