Subject: Re: Pgbouncer performance query

From: Dominique Devienne <[email-masked]>
Date: Thu, 22 Jan 2026 13:35:30 +0100

On Thu, Jan 22, 2026 at 1:29 PM KK CHN <[email-masked]> wrote:
> I agree  when I have increased the concurrent connections to 300   (pgbench -c 300 ) then  Direct hit on DB server fails with  Error too many clients as follows

Just increase max_connections then:
https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNECTIONS

Sounds like you should stick to direct PostgeSQL access, if pgBouncer
makes it 10x slower :). --DD

---

From: KK CHN <[email-masked]>
Date: Fri, 23 Jan 2026 09:54:42 +0530

My query is on the   latency average = 11.949 ms (with Pgbouncer ),     at
the same time direct hit on Database server   latency average =  1.233 ms
(Without pgbouncer)   Is this an expected  usual  behaviour  when you
employ pgbouncer ?

NOTE:   Both  pgbench tests  hit the database server   with pgbouncer  and
without pgbouncer  performed from the  pgbouncer virtual machine tty  only
not from the  database server  tty.   So how does pgbouncer running as a
separate VM  affect the  latency part ?

Or is this due to pgbouncer as a separate VM I was running  in front of the
database server ?  Somewhere I have referenced it is better to run
pgbouncer on a separate instance   to avoid  the overhead of the pgbouncer
process on the database server (?)

Or as Adrian Klaver suggested, the best solution is to run the pgbouncer on
the same database server.

What do others suggest ?

> https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNECTIONS
Already  max_connections = 500  in the postgresql.conf      You suggest to
increase  it to further (  1000 ?)

Please find the postgresql.conf   important params here ( Any thing to fine
tune ? )

listen_addresses = '*'                  # what IP address(es) to listen on;

port = 5444                             # (change requires restart)
max_connections = 500                   # (change requires restart)
shared_buffers = 128MB                  # min 128kB
dynamic_shared_memory_type = posix      # the default is usually the first
option

max_wal_size = 1GB
min_wal_size = 80MB

default_text_search_config = 'pg_catalog.english'
shared_preload_libraries =
'$libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,pg_stat_statements'

edb_dynatune = 66                       # percentage of server resources

edb_dynatune_profile = oltp             # workload profile for tuning.

timed_statistics = off                  # record wait timings, defaults to
on

Regards,
Krishane

On Thu, Jan 22, 2026 at 6:05 PM Dominique Devienne <[email-masked]>
wrote:

> > I agree  when I have increased the concurrent connections to 300
>  (pgbench -c 300 ) then  Direct hit on DB server fails with  Error too many
> clients as follows
>