привет.
хочу поставить postgresql на ssd, но при этом хочу не убить быстро ресурс ssd. есть идеи? (СУБД будет обслуживать 10 мелких сайтиков, nextcloud и gitlab)
Из ресурсов хост-системы (proxmox)  - Intel DC S4500 480 GB в RAID 1  + Toshiba P300 2TB в RAID 1

я так понимаю, нужно выносить на HDD WAL / pg_stat_tmp / pg_stat?

ну… RAC тоже в известной степени “костыли”…

Нужно хорошо понимать, для чего вам нужен кластер.
1. Просто HA (если одна из нод вышла из строя, то чтобы система продолжала работать)
2. Масштабирование read-only нагрузки и  OLAP запросов
3. Масштабирование read-write нагрузки (OLTP запросы)

Для 1) Постгрес предлагает набор "Сделай сам" - репликация с помощью потусторонних тулзов (Патрони, Сталон, ...)
2) Можно сдедать с помощью той репликации (hot standby).
Но для OLAP лучше подходят специализированные решения типа CitusDB, TimescaleDB, GreenPlum или даже Postgres-XL. Для облаков есть Amazon RDS и Aurora.
Для того, чтобы выполнять на репликах read-only запросы надо их как-то уметь отделять от апдейтов. Это можно делать на уровне приложения или с помощью pgbpool/pgbouncer-rr.
Или же использовать pgpro:multimaster
3)  обязательно подразумевает шардинг - т.е. горизонтальное партицирование. Эффективнее всего это делать на уровне приложения. Но если не возможно или не хочется, то можно использовать CitusDB, pgpro:pg_shardman

> Если что, то я про pgsql_tmp.

Я тоже. Я имел в виду — ограничить с помощью temp_file_limit, да и всё.

> но тогда мы будем на каждый коннект память выделять, независимо от того нужна она или нет.

Ничего подобного. Work_mem — просто рекомендательное "ограничение", причём на один узел запроса.
Т.е. если запросам в данной сессии столько памяти не нужно — она и не выделяется вообще.
А если требуется больше, т.е. другого выхода нет (я тут как-то приводил примеры) — PostgreSQL попробует выделить сколько нужно, проигнорировав work_mem, кстати.

> Сунуть pgsql_tmp на приемлемый по размеру рамдиск

Мой совет выше — просто чтобы с ram disk не заморачиваться. Хотя таким образом можно ограничить "в общем", минус в непредсказуемых ошибках в запросах в сессиях, когда эта память будет почти исчерпана (т.е. сессии начнут "красть" друг у друга ресурсы). ;)

> такой подход может немало оперативки сэкономить.

Каким образом (по сравнению с тем, чтобы просто ограничить)?

Так его не рекомендуется ставить под сервер СУБД (я про ssd). Ну так-то можно конечно, вопрос только на сколько его будут насиловать. У него по характеристикам перезапись всего объема каждый день в течении 5 лет.
Если будет превышать, то надо просто брать другую модель. 🤷🏻
Просто под сервер виртуализации вполне себе, но с СУБД думаю стоит брать из уровня повыше по надёжности.
имхо конечно

А вообще, по этому вопросу: +1 вот к этому https://t.me/pgsql/230997
Т.е. эти "фокусы" — почти наверняка напрасная трата времени, да и всё.

Хмм... кем не рекомендуется и почему?
И даже в отношении надёжности — современные HDD намного лучше?

Нет, речь не про hdd конечно.
Ориентирование производителя продукции.
Но опять же все зависит от задач - т.е. какой объем данных ежедневно будет переписываться на этом диске.
Я прост видимо уже сплю и пропустил что автор вопроса указал небольшие нагрузки.

А что за ссд?