Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vj8dD-007v79-05 for pgsql-general@arkaria.postgresql.org; Fri, 23 Jan 2026 04:18:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vj8dC-00Fyaz-05 for pgsql-general@arkaria.postgresql.org; Fri, 23 Jan 2026 04:18:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vj8dB-00Fyaq-1n for pgsql-general@lists.postgresql.org; Fri, 23 Jan 2026 04:18:46 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vj8d8-001siH-39 for pgsql-general@postgresql.org; Fri, 23 Jan 2026 04:18:44 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-790948758c1so18399897b3.1 for ; Thu, 22 Jan 2026 20:18:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769141922; cv=none; d=google.com; s=arc-20240605; b=J0ps5oLiirtsUBOgr8N1hwbQVyyNdfQdOJKhFEX3ZiBWTfThMdOacr3JY9YNkG9WAr pjG3210fLhJ/3yu1if8+sIx3rtwScHnLHHmnc9twWNHX8qWg82rB0GweiuzVmw0BukqL l5dVwFXkVhfuC4YO6C/oeM4lxviS3t054u7bAI+M3XW+BRvkkNsH4stJuN8rM+rCEohd m/9ED+cupgzRxRpetIyaVi9ji3XNDDY3f/aAAZU6HZYpuasm+BrCQu3rqypt0mRCqCyE eQPRTHnJk1kpaaYqqicrG6pWfGhGT8nHTRdRmGVWUU+ERkj6hV89cdiRo2pJONlJprbD PkTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Ing5oBMecoXVoTXv9hFlwgpZ3CnkImyMtdabE4wUUDE=; fh=c6RRi9dSTL1E7gogGbP/yBbCTMUdi8hMWmFPjvvXlrc=; b=Vfzvt/mqs9CjxgUuLtDPX6B+ucctyE7IJX82UzQt4GHngZg96A+y3iaaEWzqVQRu8R wHSTKo3hKgFFNApBPYWzwpHLlAD0zf/gbsAqp5IOf05CqIEDhBihx1/bfwp49r36RtJx a7ueCJvv8iuVpovVfcg3Orhc8QwJg0yt8G8hKTEI0x+38t/cJguDeQEpPR/ANO3ybov4 ANCBeUMhreiqUU1Sc2NYWQ5o7ccMyqg9dNanko8uJGQlHNXMExe2c7q7D12aWD5i0FM9 7cswBomBj+EeF6GZwGgS7EobxoBICw1JwCkhoGhs4ZJp2pVuzN5I+3bltGKzmZ8pyfVW rz+g==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769141922; x=1769746722; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ing5oBMecoXVoTXv9hFlwgpZ3CnkImyMtdabE4wUUDE=; b=d4XNNLpkLaBbnD82OXecl3s8iG2xbUA7QYRJGJWmGgl8QYvaP4/IO4/dPZ4mqzNa3P ZcRT3CJs0urKZAMbylwz6LL44sGOirNwXB0LxYhvt5Ira9QqHewwLhcCuo48buam+lcV k12rU5CoM1mfT73E1g3Zg5KMVzu4aNr8w3XuzwwP6glMM8njw0U3YR9wsWC9h5BhF8DY 40Oa3pjcgzz/KambZkdHwDYRA/rzhKMc9fCsRkKW1sITju0M99PSg3yA1mH8dk4Y0ZZH rFdceeOt59eUWHmHKYwkInV6dQIwbUJn6W9k41EVExW2WRX94D+mvuXR0HlKvnjWE0Lp X6zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769141922; x=1769746722; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ing5oBMecoXVoTXv9hFlwgpZ3CnkImyMtdabE4wUUDE=; b=fL5ze3BxvRkp3LkC1000Z+agF4YITk5GWMfeY1KIwwCtydy1RC1QT/jVWDkhTRYCdn CbXHgQYK2rqGP4IPI+cFnI05pT4rWFybGzNFYLMxuBQv2rwAV4bfIXU17fdDnRq3gdm9 kYqd0icV9viwNTjAEp7d3QCtChjns0WTskaw/pUAZO7xW2K50ynQtM9gTfdZFv+7skdj zX7POW2BKKSyEa8QaXdtM7QL+9QbH3aqw4R/gCs0cAX6KBNqxZrR+ykR9vEa2TKr4NIc mEz9BLrOhhoboK6KVVNXZ4Qmi+HC0ItXnOvqmvfvc7tQnWzft9f9EagH06rrzrxk1bAo j8JQ== X-Gm-Message-State: AOJu0YxQmKNvE9QkgT8gUH7kW9JWQU8JkZfmb8Jx6YLgjnFBFyor9u+f 2Y+AybjNLszDWGXwrM02o2ZcXJsid0EixlQnbD0bGCP3pn6i+YZKsCx9cDCfmKTU8JN7o/L5d7/ j5uig5Z7cde/o0dVQ7ZKEFlsXL6kvzZE= X-Gm-Gg: AZuq6aLAiVqBEj8oFI7MKaTcSemgvRUypQZqs4vMPCoobzSIQmJ3EYw2VMj3K1pvkjU YUrCJeWznGCEARLh5HjJOm/cFuH2x7BhvdbW61N4DzA8gBJEhAzqa2YbFDJH3Al106pBnDEmjy9 yVCIV5I8UBASmjGHytZpye5uZEYOYhoXb5uYGUsdie2RZzM3xtQHpklbOcmvvb4fwLR42JygfqV XTc3S2RIA64yDB5PpuKf0D0Gx+N6Y0Nh6E5mWofJrJgf+YlDNEVGeHrQ4TJRRfTcpGFTBSL X-Received: by 2002:a05:690c:480b:b0:786:660b:82b5 with SMTP id 00721157ae682-794398fd663mr14967217b3.27.1769141922562; Thu, 22 Jan 2026 20:18:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: KK CHN Date: Fri, 23 Jan 2026 09:54:42 +0530 X-Gm-Features: AZwV_QjHEX24MPMxthqati6TSb5NPJM2uxYqvagGgJeTzqibbQ4k1LSDS3XDj5A Message-ID: Subject: Re: Pgbouncer performance query To: Dominique Devienne Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000da05e90649067314" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000da05e90649067314 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My query is on the latency average =3D 11.949 ms (with Pgbouncer ), a= t the same time direct hit on Database server latency average =3D 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 ? > Just increase max_connections then: > > https://www.postgresql.org/docs/current/runtime-config-connection.html#GU= C-MAX-CONNECTIONS > > Already max_connections =3D 500 in the postgresql.conf You suggest t= o increase it to further ( 1000 ?) Please find the postgresql.conf important params here ( Any thing to fine tune ? ) listen_addresses =3D '*' # what IP address(es) to listen o= n; port =3D 5444 # (change requires restart) max_connections =3D 500 # (change requires restart) shared_buffers =3D 128MB # min 128kB dynamic_shared_memory_type =3D posix # the default is usually the firs= t option max_wal_size =3D 1GB min_wal_size =3D 80MB default_text_search_config =3D 'pg_catalog.english' shared_preload_libraries =3D '$libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,pg_stat_statements' edb_dynatune =3D 66 # percentage of server resources edb_dynatune_profile =3D oltp # workload profile for tuning. timed_statistics =3D off # record wait timings, defaults t= o on Regards, Krishane > On Thu, Jan 22, 2026 at 6:05=E2=80=AFPM Dominique Devienne wrote: > On Thu, Jan 22, 2026 at 1:29=E2=80=AFPM KK CHN 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 ma= ny > clients as follows > > Just increase max_connections then: > > https://www.postgresql.org/docs/current/runtime-config-connection.html#GU= C-MAX-CONNECTIONS > > Sounds like you should stick to direct PostgeSQL access, if pgBouncer > makes it 10x slower :). --DD > --000000000000da05e90649067314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


My query is on the=C2=A0 =C2=A0latency averag= e =3D 11.949 ms (with Pgbouncer ),=C2=A0 =C2=A0 =C2=A0at the same time dire= ct hit on Database server=C2=A0 =C2=A0latency average =3D=C2=A0 1.233 ms=C2= =A0 (Without pgbouncer)=C2=A0 =C2=A0Is this an expected=C2=A0 usual=C2=A0 b= ehaviour=C2=A0 when you employ pgbouncer ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0

NOTE:=C2=A0 =C2= =A0Both=C2=A0 pgbench tests=C2=A0 hit the database server=C2=A0 =C2=A0with = pgbouncer=C2=A0 and without pgbouncer=C2=A0 performed from the=C2=A0 pgboun= cer virtual machine tty=C2=A0 only not from the=C2=A0 database server=C2=A0= tty.=C2=A0 =C2=A0So how does pgbouncer running as a separate VM=C2=A0 affe= ct the=C2=A0 latency part ?


Or is this due to pgbouncer as a separate=C2=A0VM I wa= s running=C2=A0 in front=C2=A0of the database server ?=C2=A0 Somewhere I ha= ve referenced it is better to run pgbouncer on a separate instance=C2=A0 = =C2=A0to avoid=C2=A0 the overhead of the pgbouncer process on the database = server (?)

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

What do others suggest ?=C2=A0
=



<= div>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
listen_addresses =3D '*' = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# what IP add= ress(es) to listen on;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0
port =3D 5444 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # (change requi= res restart)
max_connections =3D 500 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 # (change requires restart)
shared_buffers = =3D 128MB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# m= in 128kB
dynamic_shared_memory_type =3D posix =C2=A0 =C2=A0 =C2=A0# the = default is usually the first option
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
max_wal_size =3D 1GB
min_wal_size =3D= 80MB
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
default_text_search_config= =3D 'pg_catalog.english'
shared_preload_libraries =3D '$lib= dir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,pg_stat_statements'
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
edb_dynatune= =3D 66 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 # percentage of server resources
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
edb_dynatune_profile =3D oltp =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # workload profile for tuning.
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
timed= _statistics =3D off =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0# record wait timings, defaults to on










On Thu, J= an 22, 2026 at 6:05=E2=80=AFPM Dominique Devienne <ddevienne@gmail.com> wrote:
On Thu, Jan 22, 2026 at 1:29=E2=80=AFP= M KK CHN <kkchn.= in@gmail.com> wrote:
> I agree=C2=A0 when I have increased the concurrent connections to 300= =C2=A0 =C2=A0(pgbench -c 300 ) then=C2=A0 Direct hit on DB server fails wit= h=C2=A0 Error too many clients as follows

Just increase max_connections then:
https://ww= w.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNEC= TIONS

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