2013/2/19 Robert Haas <robertmhaas@gmail.com>:
> In the department of crazy ideas, what about having pg_dump NEVER
> refresh ANY materialized views?
>
> It's true that the job of pg_dump and pg_restore is to put the new
> database in the same state that the old database was in, but I think
> you could make a reasonable case that materialized views ought to be
> an exception. After all, even with all of this infrastructure,
> chances are pretty good that the new MV contents won't end up being
> the same as the old MV contents on the old server - because the old
> MVs could easily have been stale. So why not just get the restore
> over with as fast as possible, and then let the user refresh the MVs
> that they think need refreshing (perhaps after getting the portions of
> their system that don't rely on MVs up and running)?
>
> At the very least, I think we ought to have an option for this
> behavior. But the more I think about it, the more I think maybe it
> ought to be the default.
+1 from me from a minimalist point of view.
I think of a matview of the manually refreshed kind as “can contain
stale contents (or be invalid) unless someone manually makes sure it
is up to date (or valid)”. Making any matviews invalid by default upon
restoring (itself being a manual action) would be consistent with that
definition. Additionally, ISTM to be the least arbitrary (and hence
most elegant) choice, and even more so in the context of
matviews-depending-on-matviews.
Spamming some more craziness:
Another (more elaborate) suggestion could be: Store for each matview
whether it is to be rebuilt upon restore or not. Using this setting
would intuitively mean something like “I consider this matview being
valid a precondition for considering the database state valid.”
Setting this to true for a matview would only be allowed when any
other matviews on which it depends also have this setting set to true.
Just my €0.02 of course.
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?