Melkij

Для полноты картины добавлю: по соображениям криптостойкости шифрование диска наверняка отключит использование TRIM (см. конкретную реализацию шифрования). Что при шифровании всей доступной ёмкости диска существенно ухудшит производительность I/O на дешёвых SSD - они не смогут использовать неиспользуемое пространство flash для ускорения записи (так называемый SLC кеш) потому что будут думать, что вся ёмкость занята полезными данными, а избыточной подменной ёмкости flash ради удешевления там конечно практически нет.
Скорей всего SMR HDD тоже рады не будут (да они вообще ничему не рады).

И не забудьте заранее позаботиться о бекапах.

Но по таким правилам все клиенты попадают в NAS от IP роутера (то есть типа изнутри).

Так а зачем вы делаете маскарад на входящий трафик?
https://help.mikrotik.com/docs/display/ROS/NAT

Скорей всего упираетесь в производительность IO на временных файлах, увеличение logical_decoding_work_mem с этим должно помочь.
Затем посмотрите, не упираетесь ли в 100% cpu на этом процессе. logical decoding однопоточный, ему важна производительность в один поток. Тут ничего не поможет. Прочитать, понять и переупорядочить данные среди гигабайтов wal'ов всё равно придётся.

CPU(s):                          256
On-line CPU(s) list:             0-255
Thread(s) per core:              2
Core(s) per socket:              64
Socket(s):                       2

Я не понял проблематику ситуации. 40 ядер, несколько сотен гигов RAM да пара десятков дисков - средняя железка, какие там у вас специфические проблемы такие? 40 ядер нынче не проблема даже одним сокетом получить.

Что касается памяти тут отдельная история, поступила жалоба, что U-DIMMы работают только при полной сборке (все 16), либо подключенные последовательно (с1 по 4 место например), но подключая в 1,3,7,12(например) места некоторые планки не определяются, либо сервер работает не корректно (не запускается, не стартует).

См. документацию к материнке. Там будет описано, в каком порядке необходимо заполнять слоты. Да, это стандартное требование JEDEC для DIMM'ов, что серверных, что десктопных. Технически связано с терминаторами. Затем, после требований стандарта, идёт логика как не повесить всю имеющуюся память на один и тот же канал памяти одного и того же CPU. NUMA всё-таки.
Вы правда занимаетесь серверами?

Сначала внимательно посмотрите на свой триггер, не пускаете ли вы его в бесконечную рекурсию. Нет, postgresql не будет вам мешать делать бесконечно-рекурсивный триггер и никак не будет препятствовать его выполнению до тех пор пока это будет возможно физически. И вот тут stack depth limit обычно и заканчивается первым.

Это так называемый fake raid. Удивительная поделка, объединяющая недостатки одновременно аппаратного и программного рейда, но не обладающая никакими из их достоинств.
Использовать можно только если скучно и хочется приключений.

Не забудьте настроить бекапы. Рейды с избыточностью данных это про снижение простоя, а не замена бекапам.

pvresize. Затем lvresize с resize2fs или lvcreate дальнейшие или ещё чего, смотря зачем увеличивали.

Единственный смысл добавления всё новых проводов от блока питания к материнской плате помимо 20-контактного коннектора ATX из 1995 года - уменьшение силы тока, протекающего по наиболее загруженным проводам и контактам разъёмов.

Как простое следствие этого - нет никакого физического смысла в использовании разветвителя. Это никак не уменьшит силу тока, протекающего по кабелю от блока питания. Позволит обмануть плату, если она требует чтобы оба коннектора были подключены, но это именно обман, а должны быть раздельные комплекты проводов от блока питания.

internals 64 битные
heap 32 битные

Если вы хотите чтобы ни один крупный проект не стал обновляться на такую новую версию - без проблем, поменять формат страницы heap не так уж сложно. Почему после принятия такого патча никто не станет обновляться? Потому что вместе со сменой формата страницы вы напрочь сломаете in-place pg_upgrade и вынудите обновляться только через dump+restore. Удачи это сделать на 10тб базе за обычные для pg_upgrade 5-10 минут даунтайма. А если у вас крошечная база которую можно за 10 минут обновить дампом - то вам и 64-битные xid банально не нужны и не важны.
Если интересно поподробнее, подождите запись вот этого свежего доклада

Для начала, в postgresql нет типа данных string. (а если это самодельный тип, что postgresql сделать тоже позволяет, то смотреть надо как он реализован у вас)

Для текстовых данных в postgresql есть:
- text. Просто text, без специфических ограничений на содержимое
- varchar - это всё тот же самый text. К varchar можно добавить указание ограничения максимальной длины хранимого текста в символах. Почему это отдельный тип данных? Потому что такого требование стандарта SQL
- char - фиксированный длины (в символах! в байтах они всё равно динамической длины получатся для того же utf8). Смысла его использовать в postgresql, как вы сами процитировали документацию, нет. Зачем он нужен? Потому что описан в стандарте.

В отличии от, например, mysql, для postgresql нет ничего особого в значении 255. Если в определении таблицы видно такое ограничение на 255 символов - обычно это означает именно "никто не обдумывал цель такого ограничения для этого поля, просто какое-то число"

Говоря о выборе между text или varchar(N) - varchar(N) с разумным для этих данных N предпочтительнее для коротких строк, потому что не даст записать 10мб туда где должно быть, например, не более 64 символов (это не совсем шутка, случай из практики). А по ошибке в месте записи дебажить логику приложения куда как проще, чем искать потом откуда такое взялось.