Приходилось ли тюнить PostgreSQL

Что проверяют

Понимаете ли, где именно приложение на Java теряет время на базе, и умеете ли читать план запроса. Тюнинг здесь чаще про запросы и маппинг, чем про конфигурацию сервера.

Как отвечать

Начните с того, как искали проблему, а не с параметров.

• Поиск. Статистика по запросам через pg_stat_statements, лог медленных запросов через log_min_duration_statement, метрики пула соединений. Смотреть надо на суммарное время запроса, а не только на самый долгий отдельный вызов.
• Разбор. EXPLAIN (ANALYZE, BUFFERS) на живых параметрах. Сравниваем ожидаемое и фактическое число строк: расхождение обычно значит устаревшую статистику или неудачное условие. Читаем чтения с диска и попадания в буферы.
• Правки на стороне базы. Составной индекс под реальный порядок условий, частичный индекс под горячую выборку, ANALYZE после массовой загрузки, разбор раздувания таблицы и настроек автовакуума.
• Правки на стороне приложения. Обычно они дают больше: ленивые связи и запрос вместо N+1, join fetch или граф сущностей, пакетная запись, отказ от выборки всей сущности ради двух полей, трезвый размер пула соединений.

Конфигурацию сервера правил администратор базы, так и скажите, это нормальное разделение ответственности.

Где спотыкаются

Начинают ответ с shared_buffers и work_mem. Это последний шаг, и у него есть цена: work_mem выделяется на каждую операцию сортировки в каждом соединении, поэтому щедрое глобальное значение выносит сервер по памяти под нагрузкой.

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

Третья: план снимают на пустой тестовой базе. Там последовательное чтение дешевле индексного, и вывод получается обратный тому, что будет на проде.