Melkij

Нужен explain (analyze,buffers), сильно желательно с track_io_timing = on в конфиге.

параметр work_mem на данный запрос не может оказывать почти никакого влияния

Оказывает. Если планировщик решит, что work_mem не хватает - не будет hash join. Для сортировки 27кб, очевидно, без разницы.

Впрочем, зачем вам вообще join подзапроса где одна только группировка подзапроса занимает половину времени ответа? Вам простой exists нужен.

SELECT "t1".* FROM table_1 as t1
where exists (select 1 from table_2 as t2 WHERE t1.primarykey=t2.session)
ORDER BY "starttime" DESC LIMIT 20;

А дальше know your data. Если по starttime DESC быстро находятся нужные exists - будет хорошо. Если exists мало - стоит подумать, а не денормализовать ли этот признак в table_1 с триггером для консистентности в table_2 и частичным индексом по starttime where t2_exists.

Поля session и primarykey в формате uuid

Не очень хорошая идея. Оно и сильно медленнее при сравнении относительно bigint (особенно если речь о varchar, а не uuid типе данных) и из-за случайного распределения несколько сбивает с толку статистику планировщика.

Есть у меня один зомби-процесс

Где?

user 3954 0.0 0.0 105316 952 pts/0 S+ 05:57 0:00 grep -w Z

Здесь нет ни одного зомби.

А grep в списке процессов ожидаемо есть и по условию "встречается Z" он успешно находит самого себя.

Если чуть присмотреться к пути в сообщении ошибки - то будет очевидно, что прав нет на удалённом хосте 192.168.1.27
То есть вы банально не там смотрите права. sudo разумеется работает только на локальном хосте и удалённому нет никакого дела, есть у вас рутовые права на вашей локальной системе или нет.

echo $$ вам возвращает pid оболочки, которую exec запустил. То что число находится рядом с искомым - совпадение.

Для получения pid'а собственного процесса в php существует соответствующая функция getmypid

Да, будут потеряны.

Во время переезда на массив часто массив инициализируют деградировавщим:
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/hdc1
Затем копируют на него данные и потом добавляют недостающий диск.

Подводный камень очевиден - указанной командой вы потеряли все данные. Ну или получите отлуп, если повезёт.
Не стесняйтесь поискать, вопрос миграции имеющейся системы на рейд - штука распространённая. Хотя несколько геморройная - сильно зависит от требований к даунтайму.

Суть для вашего случая: разметить sdb, инициализировать как degraded массив:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb5
Перенести всё полезное с sda на sdb, поправить загрузчик, перезагрузиться с рейда, добавить разделы sda в соответствующие массивы.
Инициализировать массив напрямую на устройство, а не разделы, возможно, но с этого устройства нельзя будет загружаться.

Разные фокусы с переносом всего полезного. Системный раздел может быть проще через dd скопировать (но раздел на sdb должен быть чуть больше, там ещё mdadm суперблок в 2048 секторов)
/home - начальную копию в 2-3 прохода rsync'ом, затем перемонтировать в ro и ещё один rsync.

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

Список дескрипторов и процессов можно получить например так:
sudo lsof -a +L1
Пример строки от меня:

COMMAND     PID   USER   FD   TYPE DEVICE   SIZE/OFF NLINK    NODE NAME
php       17455 melkij    4r   REG  254,1 1048576000     0 2624572 /home/melkij/tmpfile (deleted)

php процесс с pid 17455 удерживает deleted дескриптор файла размером в 1гб.

Далее адресно разбираться с процессами.

Один сегмент WAL обычно имеет фиксированный размер 16мб (опция компиляции postgresql with-wal-segsize, если вы её указывали - вы должны об этом знать, плюс она требует initdb делать заново). Поэтому их количество пересчитывается в объём банальным умножением.

Ограничить максимальный занимаемый объём wal сверху - нельзя. Такой единой гайки нет, даже если вас устраивает переход базы в readonly по достижении этого лимита. И есть довольно много гаек, которые при своём использовании могут попросить базу не вычищать старые wal ещё какое-то время.

Гайки, на которые надо обращать внимание:
wal_keep_segments - база оставляет на диске не меньше этого числа wal, что позволяет реплике штатно на некоторое время терять мастера и затем догонять
replication slots - если вы сделаете слот репликации и его никто не будет читать - база будет сохранять wal пока не закончится диск. Если вы используете слоты репликации, то у вас в мониторинге обязана быть отдельная проверка что слот вычитывается
max_wal_size - несмотря на название - объём wal, по накоплению которого происходит checkpoint. (либо по таймеру checkpoint_timeout смотря что случится раньше). Реально объём wal может быть выше, т.к. автоматический checkpoint намеренно не выполняется моментально, а размазан во времени.
min_wal_size - этот объём wal всегда будет на диске занят и будет переписываться по кругу. Как гарантия того, что на диске есть место под столько wal
archive_command - если включен и команда возвращает ненулевой статус возврата - то будет накапливать wal без ограничений. wal будут удалены (если только ещё не нужны какой из других настроек) когда archive_command получает от команды 0 код возврата.

Если не хочется много денег тратить на резерв свободного места на хороших SSD - разместите на SSD саму базу данных, а WAL перенесите (симлинком директории pg_xlog (до 10.0) или pg_wal (10.0 и выше)) на отдельные HDD. WAL пишутся строго последовательно, вполне возможно жить с WAL на механических дисках и держать хорошую нагрузку.
Плюс если работаете не с деньгами, можно сделать synchronous_commit = off. Что увеличит производительность всех пишущих транзакций. Но в случае фатального краха железа вы потеряете последние 3*wal_writer_delay транзакции (т.е. до 3*200мс = 600мс).

pg_basebackup
Сделает консистентную физическую копию базы. Соответственно размер бекапа примерно равен размеру кластера postgresql + накопленные за время копирования WAL.
Восстанавливаться элементарно запустив postgresql с указанием PGDATA в место где лежит результат pg_basebackup.
Им обычно реплики поднимают.

pg_dump или pg_dumpall
Логический бекап данных. Обычно не очень подходит по критерию быстро восстанавливаться т.к. при восстановлении будут перестраивать индексы, проверять fk и прочие constraint, зато как правило сильно (в пару раз без сжатия легко, со сжатием ещё больше разница) компактнее по размеру бекапа

Все из штатной поставки Postgresql. И другие способы бекапа Postgresql в основе своей опираются на них же.

#!/bin/bash
apt-get install ..
git clone ...
cd /
rm ...

Официальный установщик из debian-9.1.0-amd64-DVD-1.iso выглядит вот так:

То есть вообще-то сложно сказать, что здесь что-то принято по-умолчанию. Предлагается сразу 6 вариантов по вкусу. Если ничего не выбрать, то да, наверное это будет gnome, как первый в списке.

rsync. Старый проверенный админский молоток.
0) Монтируете оба диска
1) делаете rsync
2) повторяете команду выше до тех пор, пока время работы не придёт к какому-то допустимому промежутку
3) закрываете работу с файлами, старый диск лучше перемонтировать в ro
4) ещё один rsync
5) отмонтируете старый диск, перемонтируете новый на место старого
6) открываете работу с файлами обратно

На случай дальнейшего расширения дисков - поставьте поверх нового диска LVM. Если на старом диске уже есть LVM - то штатные pvinit, vgextend, pvmove, lvresize, vgreduce, pvremove, resizefs
Если у вас всё-таки сервер, то выясните какой стоит raid. Для программного linux raid можно доставить диски большей ёмкости без даунтайма.