ky0

Репозитории протухли. Последуйте совету и запустите:

sudo apt-get update
sudo apt install python3-pip --fix-missing

Вот честно могу ответить - ни малейших представлений как можно абстрактно сказать, сколько памяти займёт client backend процесс базы.
Это будет меняться от:
- очевидно версии базы, плюс от компилятора и настроек сборки
- session_preload_libraries, work_mem (к слову о work_mem - вы знаете, что один запрос может использовать несколько work_mem?), temp_buffers. Да ещё maintenance_work_mem для некоторых операций
- величины системного каталога - как pinned таблиц, так и затем кэшированных при обращениях
- выполняемых ранее запросов. Тот же кэш хранимых процедур у каждого backend свой

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

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

Чтобы админить калькуляторы и чайники обычно DBA не нанимают. Тем более если на том же самом калькуляторе помимо базы ещё и приложение отъедает непредсказуемо сколько памяти. Чего там от этого 1гб останется? Видимо даже shared_buffers с 128мб поднимать некуда, а то может и уменьшать придётся. Так что по опыту сложно что-то сказать о такой конфигурации.

Скорей всего не трогайте max_connections. Оставьте дефолтные 100.

Правильно ли я понимаю, что пул соединений не помогает в плане экономии оперативной памяти

Смотря какой пул и как работает приложение.
pgbouncer в pool_mode = transaction вполне может свести пару сотен подключений к баунсеру на десяток коннектов в базе. Ну а 10 процессов базы будут использовать наверняка поменьше памяти чем 200.
Для pool_mode = session - да, только сгладить стоимость fork годится.

физически бэкапить определённые базы

Не сможете.
Ну в смысле скопировать отдельные файлы можете. А вот восстановить потом - нет. Никогда.
Бекапить можно только целиком весь datadir, со всеми симлинками. Правильно объяснив базе что вы её бекапите и соблюдая ожидания базы по методу её бекапа чтобы из этого потом можно было восстановиться.

А директории баз называются идентично полю oid в pg_database

самый джентльменский вариант это реализовать нужный вам функционал в коде проекта который отправляет insert/update в бд, для этого Вам будет достаточно повесить observer insert/update на модель связанную с нужной вам таблицей. Если такой возможности нет, то через триггер как-то так.

CREATE or REPLACE FUNCTION NotifyTelegram() RETURNS text AS '
#!/bin/bash
echo say: $1 зачем тебе все это?
' LANGUAGE plsh;

-- или AFTER
CREATE TRIGGER TriggerBefore BEFORE INSERT OR UPDATE ON table_observed
    FOR EACH ROW EXECUTE PROCEDURE NotifyTelegram();

Если есть джедаи postgres поправьте меня.

Но сама идея дергания bash из триггера выглядит не очень.

href="style.css?v=<?= time()?>"

sudo apt-get install python3

Идеология работы с консолью намного более человеколюбивая чем гуи:
1) Полнота документации. man и --help работают для почти всех утилит и без сторонних сервисов позволяют найти нужные опции.
2) Простота передачи и хранения знаний. Простейший пример сборка OBS для линуха:

Никаких тысяч скриншотов и заумных ссылок. Такие же инструкции есть для большинства популярных решений.
3) Простота и скорость работы на удаленных серверах. ssh это быстро просто и надежно.
Есть для всего: от смартфонов до мака.
4) Обратная связь. 90% утилит пишут белым по черному что они делают, или какая ошибка возникла. Саму ошибку при необходимости легко загуглить.

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