Re: Materialized views WIP patch
От | Peter Eisentraut |
---|---|
Тема | Re: Materialized views WIP patch |
Дата | |
Msg-id | 512500A7.6000200@gmx.net обсуждение исходный текст |
Ответ на | Re: Materialized views WIP patch (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2/20/13 6:13 AM, Robert Haas wrote: >> It might be useful to have an option for this, but I don't think it >> > should be the default. The default should be that the new database is >> > "ready to go". >> > >> > Then again, when would you ever actually use that option? > You'd use that option if you'd rather get the database mostly-up as > soon as possible, and then worry about the materialized views > afterwards. Since the proposed materialized views are not available for implicit use in query optimization, the only way an application would make use of them is to access them directly. And if it accesses an unpopulated materialized view, it would fail. So I don't think in the current state a database is mostly-up without the materialized views filled in. I can see the value in having a restore mode that postpones certain nonessential operations, such as creating indexes or certain constraints or even materialized views. But I think the boundaries and expectations for that need to be defined more precisely. For example, a database without constraints might be considered "ready for read-only use", without secondary indexes it might be "ready for use but slow".
В списке pgsql-hackers по дате отправления: