Коллеги, приветствую! У меня возник вопрос "не отстал ли я от

жизни", а связанный он со следующим кейсом.
Есть приложение на Go использующее орм Bun в связке с PostgreSQL.
Приложение еще до запуска продовой нагрузки уже создает 200+ idle соединений к базе(Используя внутренний пул соединений орм)
Все для чего используются эти соединения - это проверка самого соединения. На текущий момент.
Сама база имеет всего 12 ядер.
При этом планируется внедрять pgBouncer, но от которого не будет никакого смысла т.к. в орм будут использовать подготовленные запросы.
Я считаю это немного дикостью, несмотря на то, что сейчас это всего лишь idle.
Неужели сейчас использовать Go с PostgreSQL так принято? Я имею в виду использовать с таким кол-вом постоянных соединений.
А как же деградация после 100+ соединений? А как же очистка ресурсов на уровне сессии, о которых надо помнить?
Я понимаю, что для Go пересоздание коннекто это тяжко. Но не жертвовать же базой...
И единственный, на мой взгляд, выход из этой "проблемы" это транзакционный мод pgBouncerа и не использовать подготовленные запросы.

Что вы думаете на этот счет? Я загоняюсь зря?

А что, размер пула не настраивается?

как я понял, настраивается, но подов много. Каждый под имеет несколько приложений и у каждого свой пул. Отсюда и кол-во соединений. Разработчики могут снизить, но не хотят

>А как же деградация после 100+ соединений? Во многом поправили, плюс она большэ для 100+ одновременно активных соединений. >А как же очистка ресурсов на уровне сессии, о которых надо помнить? Чё? И в любом случае — ну, не вечные жэ эти сэссии будут. >и не использовать подготовленные запросы. А вот это как раз дурацкая идея — поскольку prepared много могут дать и скорости и стабильности системы.

я понимаю, что можно снизить минимальное кол-во, но когда придет продовая нагрузка все эти соединения вернуться. Я хотел услышать отношение других о таком использовании. А именно о Гошных приложения с постгресом и сессионным модом пгбаунсера.

С такой же проблемой столкнулись, есть инфа что баунсер в новой версии научился с prepared statement работать, но мы еще только собираемся тестить это

Всегда умел (только архитектор нужэн толковый, да).

А можно поподробнее? У нас орм и мы не могли в ней переключать режимы

Где искать толковых архитекторов? Не знаю, всё сложно.

Ну и ладно)

Последняя версия pgbouncer поддерживает prepared stayements

Да, новая версия может. Но это только только ввели. Что то страшновато внедрять в прод это

Причем по описание подразумевается, что подготовленные запросы не являются основной нагрузкой базы. А в случае работы с орм - подготовленных 99%

Что значит " не являются основной нагрузкой"? В общем там это сделано достаточно эффективно и тестировалось тоже достаточно хорошо. Ес-но это не гарантирует отсутствие проблем. Например мы недавно наступили на одну - приложение выполняло deallocate all для очистки препарнутых стайтментов, и так как pgbouncer это не детектил, то весь маппинг шёл лесом. Сейчас закомммтили фикс. Но когда он ещё попадет в релиз...

а можно игнорить комменты в текстах запросов, как в pg_stat_statements?

Я сделал такой вывод учитывая параметр, который определяет как много подготовленных уникальных запросов нужно хранить в соединении. Подумал - значить не подразумевается, что все запросы будут подготовленными.