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".