The database keeps transaction logs in the pg_wal directory.

The max size of this directory is defined by the config setting max_wal_size.

The database will on schedule flush those transactions logs. It does this through a mechanism known as checkpointing.

The database spreads the cost of flushing those over time to reduce resource contention. This is determined by the config setting checkpoint_timeout and checkpoint_completion_target.

If your database is transactionally heavy or has heavy periods it can produce transactions log at a rate faster than it can checkpoint.

This causes the flushes to happen more frequently which can cause resources to be consumed unnecessarily.

To help prevent this you can increase the size allowed in this directory by adjusting the max_wal_size setting.

max_wal_size controls the total size of all WAL segments, not the size of each segment.

So with a value of 2GB, you are saying that about 128 of those segments can be created before they get re-used.

The hint is about increasing the total number of files (hence the mentioning of max_wal_size), it's not about the size of each segment (file).

Up to Postgres 10, the size of each segment is fixed to 16MB

Starting with Postgres 11, you can change the size of each segment but only when you initialize a new database cluster (but again: that's not what that hint is about).

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:

• Configuring PostgreSQL for write performance

Postgres 9.5

The upcoming new release has a smarter approach. Quoting the beta release notes:

Replace configuration parameter checkpoint_segments with min_wal_size and 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 max_wal_size has been increased to 1GB.

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.