Re: Materialized views WIP patch
От | Robert Haas |
---|---|
Тема | Re: Materialized views WIP patch |
Дата | |
Msg-id | CA+TgmoahDmiGRSFVbTv=_ZyMDJD4a2DeixRV-fbiAmqdfO91SA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Materialized views WIP patch (Kevin Grittner <kgrittn@ymail.com>) |
Ответы |
Re: Materialized views WIP patch
Re: Materialized views WIP patch |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: