Not uncommon during a whole-DB restore because that's an exceptionally huge operation. If you see this during normal operation, consider raising your setting for
checkpoint_segments permanently, just like the error message hints.
You might go to the trouble of setting
checkpoint_segments higher just before the restore and then lower it again. This is even what the manual suggests (including an explanation):
Temporarily increasing the
checkpoint_segments configuration variable
can also make large data loads faster. This is because loading a large
amount of data into PostgreSQL will cause checkpoints to occur more
often than the normal checkpoint frequency (specified by the
checkpoint_timeout configuration variable). Whenever a checkpoint
occurs, all dirty pages must be flushed to disk. By increasing
checkpoint_segments temporarily during bulk data loads, the number of
checkpoints that are required can be reduced.
Related answer with more details:
The upcoming new release has a smarter approach. Quoting the beta release notes:
Replace configuration parameter
max_wal_size (Heikki Linnakangas)
This allows the allocation of a large number of WAL files without
keeping them if they are not needed. Thus the default for
has been increased to
Aside: the number of views is barely relevant, those do not contain any data, just the "recipe", i.e.: the query and some attributes of the view. For the question at hand, basically only the total size of the backup file matters.