On Mon, Feb 18, 2013 at 4:48 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> This should allow me to simplify the code a little bit and move the
> RMV step to the very end. That may have some advantages when users
> want to start using the database while MVs are being populated.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company