Наличие пуллера на стороне приложения не отменяет необходимости в пуллере  СУБД.

Страх тащить новое и неизведанное в пром это скорее хорошо. Но Вы не будете бояться, если хорошо изучите как работает Patroni и алгоритм RAFT. Далее Вам стоит попрактиковаться в тестовом окружении.

Используйте готовый инсталятор кластера,
и желательно параллельно разобраться в настройке с нуля руками.
P. S. На боевых серверах вручную не советую.

Спасибо. Попробую)

День добрый, а можно по детальней плз, зачем пул БД когда есть пул приложения?

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

Понял, спасибо

По той же причине, экономия на количестве воркеров на стороне СУБД - уменьшение кол переключений контекста , ProcArrayLock`s, backend forks ...
Если у Вас 1 или 2 бэкэнда с десятком соединений, то можно и напрямую к субд. Но если у Вас, к примеру, микросервисная архитектура, и таких бэкэндов (со своими пулами) десятки и сотни, Вы получите огромное кол простаивающих (idle) сессий на стороне БД.
В общем, при большом количестве соединений (как правило больше чем количество физических ядер CPU в системе), запросы начинают работать медленней чем могли бы.

Нужен мониторинг, отслеживать сколько фактических активных соединений (за период времени, чтобы учесть пиковые нагрузки).

Пример:

Total 19, но фактически используется до 5-и воркеров. Плохо когда "серых" - idle сотни и тысячи...

Не, у нас не микро сервисы, и макс соединение 20 штук)
Пул только на приложении

У нас сейчас так и мы выросли из этого горшочка. Проблема №1 - когда один сервис обрастает траффиком, он начинает пожирать больше connection pools в pgbouncer, соответственно больше active connections в PG, а один инстанс ограничен в max active connections по кол-ву RAM (как например в GCP), проблема №2 - вертикальное масштабирование инстанса кладёт все базы, если используете pgbouncer, то можно поставить на паузу, но в зависимости от траффика, может накопиться очень много запросов. Проблема №3 - апгрейд одной базы допустим с PG 9 на PG 12 может иметь несовместимости и тогда придётся писать миграции на все базы одним махом, а не мигрировать по одной. Мы рассматриваем вариант Patroni+Spilo от Zalando, но есть проблемы с их postgres-operator, он выкатывает всего один connection pooler и мы пока не понимаем как разделять read/write стримы (как коннектиться к мастеру или слейву) через этот пулер.

можно переность по одной безе с 9 на 12 и переключать аппликейшены , начиная с небольших баз, ну и разносить на отдельные инстанцы если нужно, отделить  можно только большие БД.

hi all
how add duplicate id
a left join b
a1 b1
a1 b2
a1 b3
a2 b4
a2 b5
——
but i need
a1 1 b1
a1 2 b2
a1 3 b3
a2 1 b4
a2 2 b5

row_number() OVER (PARTITION BY col1 ORDER BY col2) ?

thanks, PARTITION BY working for me
cool 🔥👍💪

Всем привет. Не подскажете как добавить значение в проверке check ?
type project_type DEFAULT 'regional' CHECK (type = 'regional')

У нас конечно все игрушечных размеров, но разделение read only VS write есть в самом приложении которое берет соединение ито из одного то из другого пула

Это при условии что вы используете patroni?

Всем привет, а подскажите, какой правильно поставить индекс на запрос, где explain analyze показа следующее

->  Parallel Seq Scan on aggregate_matches m  (cost=0.00..956907.79 rows=3 width=439) (actual time=13329.856..45352.223 rows=14 loops=3)
  Filter: ((answer_func_id IS NOT NULL) AND (answer_act_id IS NULL) AND (source_qual_id = 1116) AND (answer_qual_id = 1116) AND (source_qual_type = 'q_core'::text) AND (answer_qual_type = 'q_core'::text))