Re: Pgbouncer

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Pgbouncer
Дата
Msg-id 379ce1a5b087e6bcc621325d0935b771ed161d43.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Pgbouncer  (Raj <rajeshkumar.dba09@gmail.com>)
Список pgsql-admin
On Thu, 2025-09-11 at 22:11 +0530, Raj wrote:
> I am asking should we use pgbouncer? If so, what's the compelling situation
> despite having postgres inbuilt timeout parameters.

Timeouts and connection pooling have little to do with each other.

You want timeouts so that statements and transactions cannot take too long,
hog resources and damage your database.

Connection pooling has a different purpose.  It is necessary, because you
cannot afford to have short-lived database sessions.  So you want persistent
database session, but you don't want too many of them because

- the more you have, the bigger the risk of overloading the database

- if you have many connections, you cannot set "work_mem" too high, which
  will be bad for the performance of your SQL statements

- switching between processes means overhead for the kernel

- the more sessions you have, the longer the snapshot PostgreSQL takes at
  the start of each statement will take

If you have a single application server, you don't need pgBouncer.  Simply
use the connection pooler built into your application server.  Only when you
start many instances of your application server (which would mean many pools)
you need an external pooler like pgBouncer.

If you want more reading material:
https://www.cybertec-postgresql.com/estimating-connection-pool-size-with-postgresql-database-statistics/
https://www.cybertec-postgresql.com/tuning-max_connections-in-postgresql/
https://www.postgresql.eu/events/pgconfeu2022/sessions/session/3811/slides/327/1000_application_users.pdf

Yours,
Laurenz Albe



В списке pgsql-admin по дате отправления: