Вот честно могу ответить - ни малейших представлений как можно абстрактно сказать, сколько памяти займёт 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 годится.
