ky0

Для базы такого размера подойдёт pg_dump.

Если версии и расположение СУБД одинаковые - переноса каталога $PGDATA и всех tablespace`ов должно быть достаточно. Что в логах при попытке запуска?

Не выдумывайте и юзайте стандартный, многократно проверенный вариант - мастер, слейвы + архив WAL`ов + бэкапы.

Сортируете в другую таблицу, первую удаляете, переименовываете. Но так делать не надо.

Зачем городить велосипед? На share.zabbix.com и просторах интернета есть несколько неплохих шаблонов - отчекрыжьте не нужное вам и всё.

Для минорных версий можно подсунуть. Для мажорных:
https://www.postgresql.org/docs/10/static/pgupgrad...

Очевидно, нужно как-то секционировать данные по нужному признаку, тем самым уменьшив размер, либо один раз создать небольшой по размеру снапшот и затем применять к нему те же изменения, что и к продакшену.

Вообще странно, что вам для разработки приходится что-то воссоздавать - обычно бывает наоборот, сначала нововведения накатываются на двевлоперскую и тестовую базы и только затем на прод.

Нужно не считать, сколько памяти занимает СУБД, а настраивать её в соответствии с желаемым объёмом потребления, см. например - http://pgtune.leopard.in.ua. Причина этого проста - при активном использовании постгрес рано или поздно займёт всю доступную ему память и это совершенно нормально.

pg_dump/pg_basebackup => pg_restore.

Если нужна не целая база - переносите отдельные таблицы, так будет быстрее.

Поддерживаю насчёт pg_stat_statements, есть масса способов извлечь оттуда полезную информацию, см. например https://github.com/dataegret/pg-utils

Определитесь, хотите вы устанавливать СУБД из пакета (да, файлы будут "разбросаны по файловой системе") или чтобы всё это компактно находилось внутри одного каталога, что позволяет без проблем манипулировать этим хозяйством руками.

В первом случае, как вам посоветовал Сергей Горностаев - просто подключайте репозиторий с устраивающей вас версией и апгрейдитесь. Во втором - устанавливайте из дистрибутива, указав при инсталляции подходящий вам каталог.

Кастомный формат (по сравнению с plaintext) поддерживает многопоточное восстановление - это его главное преимущество. Directory лучше архивируется и его проще редактировать.

У постгреса есть встроенные механизмы, делающие примерно то же самое - часто используемые данные кэшируются в памяти. Всю базу хранить в памяти - несколько другое, обычно это и не требуется, при достаточном объёме выданной СУБД памяти.

Из релевантных параметров - отключение fsync (не рекомендую) и synchronous_commit.

EMS SQL Manager for PostgreSQL, в бесплатной версии до пяти сохранённых баз и нет SSH-туннелей.

pg_dump, ssh, pg_restore. Можно в одну строчку с использованием пайпов. В случае, если база здоровая, я бы сделал не через дамп/рестор, а через pg_basebackup.

Релевантное обсуждение на SO - https://stackoverflow.com/questions/1237725/copyin...

Вынесите данные, к которым часто обращаются в отдельный таблеспейс, расположенный на более производительных дисках, например SSD.

Нет ничего страшного в том, чтобы DBA знали пароль от юзера postgres, намного важнее ограничить возможность подбора пароля снаружи, например, с помощью pg_hba разрешив только локальный коннект.