public inbox for [email protected]
help / color / mirror / Atom feedPgbouncer
4+ messages / 3 participants
[nested] [flat]
* Pgbouncer
@ 2025-09-11 13:31 Raj <[email protected]>
2025-09-11 13:55 ` Re: Pgbouncer hubert depesz lubaczewski <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Raj @ 2025-09-11 13:31 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
We are migrating from oracle.to postgres and its done.
Now as a DBA, to improve performance say idle connecting handling or
anything, if I want to recommend pgbouncer to the team, what's the
compelling reason would it be?
I may ask them to handle connections from application end and they may say
ok but we still.may see idle connections are not closed.
So, at point and for what compelling reason I should tell my manager, we
must go-ahead and use etc.
We use pg17 and in postgres itself I know idle_session_timeount,
transaction_timeout, statement_timeout. Is this enough? Will it abruptly
kill queries and if so, isn't it bad?
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Pgbouncer
2025-09-11 13:31 Pgbouncer Raj <[email protected]>
@ 2025-09-11 13:55 ` hubert depesz lubaczewski <[email protected]>
2025-09-11 16:41 ` Re: Pgbouncer Raj <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: hubert depesz lubaczewski @ 2025-09-11 13:55 UTC (permalink / raw)
To: Raj <[email protected]>; +Cc: Pgsql-admin <[email protected]>
On Thu, Sep 11, 2025 at 07:01:26PM +0530, Raj wrote:
> We are migrating from oracle.to postgres and its done.
>
> Now as a DBA, to improve performance say idle connecting handling or
> anything, if I want to recommend pgbouncer to the team, what's the
> compelling reason would it be?
https://www.depesz.com/2012/12/02/what-is-the-point-of-bouncing/
> I may ask them to handle connections from application end and they may say
> ok but we still.may see idle connections are not closed.
>
> So, at point and for what compelling reason I should tell my manager, we
> must go-ahead and use etc.
>
> We use pg17 and in postgres itself I know idle_session_timeount,
> transaction_timeout, statement_timeout. Is this enough? Will it abruptly
> kill queries and if so, isn't it bad?
statement_timeout and transaction_timeout have the power to kill
queries, yes.
Best regards,
depesz
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Pgbouncer
2025-09-11 13:31 Pgbouncer Raj <[email protected]>
2025-09-11 13:55 ` Re: Pgbouncer hubert depesz lubaczewski <[email protected]>
@ 2025-09-11 16:41 ` Raj <[email protected]>
2025-09-12 05:26 ` Re: Pgbouncer Laurenz Albe <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Raj @ 2025-09-11 16:41 UTC (permalink / raw)
To: [email protected]; +Cc: Pgsql-admin <[email protected]>
I am asking should we use pgbouncer? If so, what's the compelling situation
despite having postgres inbuilt timeout parameters.
On Thu, 11 Sept 2025, 19:25 hubert depesz lubaczewski, <[email protected]>
wrote:
> On Thu, Sep 11, 2025 at 07:01:26PM +0530, Raj wrote:
> > We are migrating from oracle.to postgres and its done.
> >
> > Now as a DBA, to improve performance say idle connecting handling or
> > anything, if I want to recommend pgbouncer to the team, what's the
> > compelling reason would it be?
>
> https://www.depesz.com/2012/12/02/what-is-the-point-of-bouncing/
>
> > I may ask them to handle connections from application end and they may
> say
> > ok but we still.may see idle connections are not closed.
> >
> > So, at point and for what compelling reason I should tell my manager, we
> > must go-ahead and use etc.
> >
> > We use pg17 and in postgres itself I know idle_session_timeount,
> > transaction_timeout, statement_timeout. Is this enough? Will it abruptly
> > kill queries and if so, isn't it bad?
>
> statement_timeout and transaction_timeout have the power to kill
> queries, yes.
>
> Best regards,
>
> depesz
>
>
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Pgbouncer
2025-09-11 13:31 Pgbouncer Raj <[email protected]>
2025-09-11 13:55 ` Re: Pgbouncer hubert depesz lubaczewski <[email protected]>
2025-09-11 16:41 ` Re: Pgbouncer Raj <[email protected]>
@ 2025-09-12 05:26 ` Laurenz Albe <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Laurenz Albe @ 2025-09-12 05:26 UTC (permalink / raw)
To: Raj <[email protected]>; [email protected]; +Cc: Pgsql-admin <[email protected]>
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-statist...
https://www.cybertec-postgresql.com/tuning-max_connections-in-postgresql/
https://www.postgresql.eu/events/pgconfeu2022/sessions/session/3811/slides/327/1000_application_user...
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-09-12 05:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-09-11 13:31 Pgbouncer Raj <[email protected]>
2025-09-11 13:55 ` hubert depesz lubaczewski <[email protected]>
2025-09-11 16:41 ` Raj <[email protected]>
2025-09-12 05:26 ` Laurenz Albe <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox