В бета версии PostgreSQL 8.4 в утилите pg_restore появилась поддержка возможности загрузки дампа 
в несколько параллельных потоков. Например, загрузка дампа базы размером 300 Гб
на 8-ядерном сервере
занимала стандартным образом 12 часов, при распараллеливании процесса загрузки на 8 потоков, 
время загрузи сократилось до 3 часов. Полная перезагрузка дампа базы может
понадобиться например при миграции
с PostgreSQL  8.2 на 8.3 или при переходе с 32- на 64-разрядную сборку системы.

Огромным плюсом является и то, что параллельный вариант pg_restore 
из ветки 8.4 прекрасно работает  с ветками 8.2 и 8.3.

Рассмотрим процесс миграции с 8.2 на 8.3. На рабочей машине дополнительно
установим в отдельную директорию бета версию 8.4:

   ./configure --prefix=/usr/local/pgsql84
   make
   make install 

Создаем дамп работающей базы PostgreSQL 8.2, использую утилиту pg_dump из состава  PostgreSQL 8.3:

   /usr/local/pgsql83/bin/pg_dump -F c -v -f my_db.dump my_database

В зависимости от конфигурации дополнительно может потребоваться сделать дамп ролей:

   /usr/local/pgsql83/bin/pg_dumpall -g -f my_roles.dump

Восстанавливаем роли:

   /usr/local/pgsql83/bin/psql -f my_roles.dump postgres

Запускаем процесс параллельного восстановления базы, число потоков задается
через опцию -j, в нашем случае
используется загрузка в 8 потоков. При указании большого числа потоков нужно
быть уверенным, что система
ввода/вывода не окажется узким местом, т.е. база размещена на высокопроизводительном хранилище:

   /usr/local/pgsql84/bin/pg_restore -F c -j 8 -v -C -f my_db.dump

Дополнительно можно упомянуть, что в рамках проекта EnterpriseDB ведется
разработка утилиты pg_migrator
(http://pgfoundry.org/projects/pg-migrator/), позволяющей осуществлять перенос
базы на новый сервер
без остановки работы СУБД. Но  pg_migrator к сожалению находится еще на стадии альфа тестирования.


Некоторые советы по оптимизации процесса создания дампа и его восстановления:

* Во время восстановления можно отключить fsync режим и autovacuum, значительно
увеличить размер памяти
(до 1 Гб если памяти много), заданный в параметрах конфигурации work_mem и maintenance_work_mem, 
при этом  размер wal_buffers и checkpoint_segments также нужно увеличить до 16 или 32 Мб;

* При наличии больших GIN или GiST индексов, время восстановления которых
нередко занимает 75% от всего времени
восстановления, если без этих индексов можно себе позволить немного поработать,
имеет смысл разделить
процесс восстановления на две стадии: восстановление первичных данных, запуск БД в продакшин, 
восстановление GIN или GiST индексов уже на работающей базе.

* Всегда следует использовать pg_dump из более новой версии PostgreSQL, а не из
старой, апгрейд которой производится.

* Для продакшин систем, время и наличие возможных подводных камней стоит предварительно оценить, 
выполнив тестовые dump/restore без остановки первичной базы;