首先检查磁盘设置是否获得了合理的IO性能。然后检查您的PostgreSQL安装是否已适当调优。特别是shared_buffers应该正确设置，maintenance_work_mem应该在恢复期间增加，full_page_writes应该在恢复期间关闭，wal_buffers应该在恢复期间增加到16 MB，checkpoint_segments应该在恢复期间增加到16，您不应该有任何不合理的登录（类似于记录执行的每个语句），在恢复期间应禁用auto_vacuum。
如果您使用的是8.4，也可以尝试使用并行恢复，即pg_restore的--jobs选项。

改进pg dump&restore

PG_转储|始终使用format-directory和-j选项

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

PG_RESTORE|始终使用postgres.conf和format-directory以及-j选项的调优

work_mem = 32MB
shared_buffers = 4GB
maintenance_work_mem = 2GB
full_page_writes = off
autovacuum = off
wal_buffers = -1

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/

两个问题/想法：
1.通过指定-Fc，pg_dump输出已被压缩。压缩不是最大的，所以你可能会发现使用“gzip-9”可以节省一些空间，但我敢打赌，这不足以保证压缩和解压缩备份的-Fc版本所需的额外时间（和I/O）。
1.如果您使用的是PostgreSQL 8.4.x，则可以使用新的pg_restore命令行选项“-j n”来加快从-Fc备份恢复的速度，其中n=用于恢复的并行连接数。这将允许pg_restore加载多个表的数据或同时生成多个索引。

我想你需要备份，而不是数据库的重大升级。
对于大型数据库的备份，您应该设置continuous archiving而不是pg_dump。
1.设置WAL存档。
1.例如，每天使用以下命令进行基本备份

psql template1 -c "select pg_start_backup('`\`date +%F-%T\``')"
rsync -a --delete /var/lib/pgsql/data/ /var/backups/pgsql/base/
psql template1 -c "select pg_stop_backup()"

还原将与从备份位置还原不早于pg_start_backup时间的数据库和WAL日志并启动Postgres一样简单。而且会快得多。

zcat dumpfile.gz | pg_restore -d db_name

删除未压缩数据到磁盘的完整写入，这是当前的瓶颈。

您可能已经简单地通过压缩备份可以提高性能这一事实猜到，您的备份是I/O绑定的。这并不奇怪，因为备份几乎总是受到I/O的限制。压缩数据可以用I/O负载来交换CPU负载，而且由于大多数CPU在海量数据传输期间处于空闲状态，因此压缩是一种净收益。
因此，要加快备份/恢复时间，您需要更快的I/O。除了重新组织数据库使其不是一个巨大的单个示例之外，这几乎是您所能做的全部工作。

如果您遇到pg_restore的速度问题，请检查是否使用INSERT或COPY语句转储数据。
如果使用INSERT（pg_dump是通过--column-inserts参数调用的），数据恢复速度会明显变慢。
使用INSERT可以很好地将转储文件加载到非Postgres数据库中。但是如果你恢复到Postgres，在使用pg_dump时省略使用--column-inserts参数。