Re: Materialized views WIP patch
От | Robert Haas |
---|---|
Тема | Re: Materialized views WIP patch |
Дата | |
Msg-id | CA+TgmobM04k=OK1rUuEkK4i26_JSsiksmnEx5R4BnhN42=Xoow@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 Fri, Feb 15, 2013 at 8:01 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > There is one odd aspect to pg_dump, but I think the way it is > behaving is the best way to handle it, although I invite other > opinions. If you load from pg_dump output, it will try to > populated materialized views which were populated on dump, and > leave the ones which were not scannable because the contents had > not been generated in an empty and unscannable state on restore. > That much seems pretty obvious. Where it gets a little tricky is > if mva is generated with data, and mvb is generated based on mva. > Then mva is truncated. Then you dump. mvb was populated at the > time of the dump, but its contents can't be regenerated on restore > because mva is not scannable. As the patch currently stands, you > get an error on the attempt to REFRESH mvb. I think that's a good > thing, but I'm open to arguments to the contrary. Hmm, anything that means a dump-and-restore can fail seems like a bad thing to me. There's nothing outrageous about that scenario. It's arguable what state dump-and-restore should leave the new database in, but I don't see why it shouldn't work. I predict we'll end up with unhappy users if we leave it like this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: