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.94.2) (envelope-from ) id 1vBjRC-004Dow-C8 for pgpool-general@arkaria.postgresql.org; Thu, 23 Oct 2025 00:44:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vBjRA-002V86-QN for pgpool-general@arkaria.postgresql.org; Thu, 23 Oct 2025 00:44:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vBVOt-00F1Pd-FX for pgpool-general@lists.postgresql.org; Wed, 22 Oct 2025 09:44:58 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vBVOq-003amT-0b for pgpool-general@lists.postgresql.org; Wed, 22 Oct 2025 09:44:58 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-58affa66f2bso7862942e87.1 for ; Wed, 22 Oct 2025 02:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761126295; x=1761731095; darn=lists.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=wssCzLT9zsqWohjtaEsqieSwNxkhHBM6TFrfHOfVIS8=; b=VFrpIqz+R/gfEeoCZ4FoOyjYQPQZd/Y+Svkzeb7a4iO3xETN/lOGdiNk7srjgaC7F6 VsKdJ0e9TkHnoO8nhQCjVem6ZDXVla4cys5v+tVdSTz5yGzMng3/IujnRrQ+R6ATvwbF aqvmWl7LMuMblSz8C21fHt1F4wBHd9HTxkEeepnGcxpD+b7G7P2ngyCG0x/Cm/8wZDU8 eJ7/dveVq8vFS5hSO9svWF/l3EyHintGYjSw2DR4O3aVeHX/fQ2xyG2cOTFLjVzFSmkk jrBDG9a2/4ze5SMpsF/efARZUnMGkVkRiwBhlByXlJfuaxgyCSzQRRc6re/tHHmKn2JM lCMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761126295; x=1761731095; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wssCzLT9zsqWohjtaEsqieSwNxkhHBM6TFrfHOfVIS8=; b=Ex3JGCdUIkfpavi7Arl1FAGdzAETZSIyn7rLC58UEPd9rAyRrcE/SLsLFQJBsnvIX2 3qZnFDrfIq1qsHBf2Q6WQYsbqpjcgueNs0JMOZ+/5xNOypQ447yzKDtJkA3tnV7BRZh3 h4nWYmkinzCxQDLuQVtuLKDlQa4PcehYUcn6Smn36DDl/LZcvLqWXwzCSEBVPpOhmTEK XExc9hVbDObfTZqUeqKDAfrxjha01n5xZrRHjlrQnAGyJMSDKbV8kJHBpAPKdF9wOmtn yN2o3tBPDaDF/2VvCDhm5Xw9GbSQgvNTgF4YjbEWQzsHyhSPiI27+MnXh0hx+wwFVxlQ B9tw== X-Gm-Message-State: AOJu0YyNGhtgaBB/njKlG1W4YyKq5nuG1dwkLRZtxy7UZOIC2BsLtU24 i9M0OAFppxoNgNUA/Qsmd9tLSEGiFLxt+xdh9zVgVidfY+khjYZZ+PLmDVg0QyscC11Zzur0Pfx UgG+vVSoo3UlnizmJlXpV1mgVz0u4UOLvfFEH X-Gm-Gg: ASbGncvSDguA+oQVVXgDZMRJYaGk6ztOK2JoMG85Euhg+F7ku9rQUhTwOCFIStZjFo/ Q7FVzPX8AsfsDBfX3TB8nB/xBfio3LCwqz/vtCdjP0Fedf7d7IpfRnnmvdp8UNvt3luoAUfCztS ZoIR1yhdqgbj4k5Fs7H9p1Bq+R33Refpp754yOH6xlom3glDasn0IXOcDDehEFrMTBpSMn79ytT 1NHosLZTVG0tmYG77B29Sweueee2Or+BhBcAor4ohpG94IBFM2oXZhhZTSFUzrT X-Google-Smtp-Source: AGHT+IFoO+rKoM8CmMXMxotYu0Qgx4zHFLdaaJYfYMGrTHhrO+gVtrmCj10r5sEM4T6MwLMgi6yb2dtqsIw5uvJZkMI= X-Received: by 2002:a2e:9fcb:0:b0:36a:f4d3:82e9 with SMTP id 38308e7fff4ca-3779781ea8fmr60759381fa.6.1761126294337; Wed, 22 Oct 2025 02:44:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bob Ross Date: Wed, 22 Oct 2025 11:44:43 +0200 X-Gm-Features: AS18NWCXUljohozStaK0ijVQUngYqiz5lIY8fq4Q7mQx4GFNByrNB-PxA6bEP3s Message-ID: Subject: Re: SQL query latency when using pgPool (v4.6.2) To: Bo Peng Cc: pgpool-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000002dbc760641bc2be4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002dbc760641bc2be4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ++ pgpool-general@lists.postgresql.org as missed it by accident. On Wed, Oct 22, 2025 at 11:40=E2=80=AFAM Bob Ross wrote: > Hi Bo, > > I was able to narrow down the issue and reported it as a bug: > https://github.com/pgpool/pgpool2/issues/130 > All required information regarding versions is in the link. Affected > pgPool is colocated with Postgres in the local (primary) region. > See our pgpool.conf attached but it's quite irrelevant as this issue > occurs with any parameter combination, as long as there are both local an= d > remote nodes configured as backends. > Logs are clean, the only difference is the delay between SQLs when remote > nodes are attached (~20ms delay) and detached (~1ms delay). > > For us this is a blocker - we are unable to use pgPool effectively in > multi-region Postgres deployment. > Please let us know in case of any further questions. > > Thanks, > Bob > > On Fri, Oct 17, 2025 at 9:42=E2=80=AFAM Bo Peng wro= te: > >> Hi, >> >> Thank you for your question. >> >> Could you please share the cluster configuration? >> (For example, the number of nodes, Pgpool-II/PostgreSQL versions, and >> whether pgpool and PostgreSQL are running on the same host.) >> >> Also, could you please share your pgpool.conf file and the pgpool logs? >> >> --- >> Bo Peng >> SRA OSS K.K. >> TEL: 03-5979-2701 FAX: 03-5979-2702 >> Mobile: 080-7752-0749 >> URL: https://www.sraoss.co.jp/ >> >> >> ________________________________________ >> =E5=B7=AE=E5=87=BA=E4=BA=BA: Bob Ross >> =E9=80=81=E4=BF=A1: 2025 =E5=B9=B4 10 =E6=9C=88 8 =E6=97=A5 (=E6=B0=B4= =E6=9B=9C=E6=97=A5) 15:30 >> =E5=AE=9B=E5=85=88: pgpool-general@lists.postgresql.org < >> pgpool-general@lists.postgresql.org> >> =E4=BB=B6=E5=90=8D: SQL query latency when using pgPool (v4.6.2) >> >> >> >> >> Hello, >> I am currently testing SQL query performance using PgPool (v4.6.2) as a >> load balancer, and I am observing approximately 18=E2=80=9320 ms latency= between >> SQL statements within the same transaction. Execution time on the >> PostgreSQL backend servers is less than 0.5 ms. >> It=E2=80=99s important to note that both the application and database se= rvers are >> located in the same cloud region, with network latency below 1 ms. PgPoo= l >> is colocated with the PostgreSQL backend servers. >> For example, when executing a transaction containing 10 SQL statements, >> the total execution time through pgPool is about 200 ms, as confirmed by >> both application and pgPool logs. The delay consistently occurs between = the >> =E2=80=9CExecute=E2=80=9D and =E2=80=9CParse=E2=80=9D phases. When conne= cting directly to the PostgreSQL >> backends, the same transaction completes in about 10 ms, with roughly 1 = ms >> between SQL statements. >> We have tested the following configurations: >> - Switched from the extended query protocol to the simple query protocol >> =E2=80=94 for some queries this reduced inter-query latency to 2=E2=80= =933 ms, but for >> others it increased to 30=E2=80=9340 ms due to additional parsing overhe= ad. >> - Adjusted various PgPool parameters related to load balancing and >> connection pooling (e.g., load_balance_mode, statement_level_load_balanc= e, >> serialize_accept, disable_load_balance_on_write) and enabled debug loggi= ng, >> but none of these changes brought a significant improvement. >> Could you please advise whether there are additional pgPool parameters o= r >> tuning approaches that could help improve throughput and reduce latency = in >> extended query protocol? >> Thank you, >> Bob >> > --0000000000002dbc760641bc2be4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
++ =C2=A0pgpool-general@lists.postgresql.org as missed it= by accident.

On Wed, Oct 22, 2025 at 11:40=E2=80=AFAM= Bob Ross <bob.ross.19821@gm= ail.com> wrote:
Hi Bo,

I was able to narrow down= the issue and reported it as a bug:=C2=A0https://github.com/pgpool/pgpool2= /issues/130
All required information regarding versions is in= the link. Affected pgPool is colocated with Postgres in the local (primary= ) region.
See our pgpool.conf attached but it's quite irrelev= ant as this issue occurs with any parameter combination, as long as there a= re both local and remote nodes configured as backends.
Logs are c= lean, the only difference is the delay between SQLs when remote nodes are a= ttached (~20ms delay) and detached (~1ms delay).

F= or us this is a blocker - we are unable to use pgPool effectively in multi-= region Postgres deployment.
Please let us know in case of any fur= ther questions.

Thanks,
Bob
<= br>
On Fri,= Oct 17, 2025 at 9:42=E2=80=AFAM Bo Peng <pengbo@sraoss.co.jp> wrote:
Hi,

Thank you for your question.

Could you please share the cluster configuration?
(For example, the number of nodes, Pgpool-II/PostgreSQL versions, and wheth= er pgpool and PostgreSQL are running on the same host.)

Also, could you please share your pgpool.conf file and the pgpool logs?

---
Bo Peng <pengbo= @sraoss.co.jp>
SRA OSS K.K.
TEL: 03-5979-2701 FAX: 03-5979-2702
Mobile: 080-7752-0749
URL: https://www.sraoss.co.jp/


________________________________________
=E5=B7=AE=E5=87=BA=E4=BA=BA: Bob Ross <bob.ross.19821@gmail.com>
=E9=80=81=E4=BF=A1: 2025 =E5=B9=B4 10 =E6=9C=88 8 =E6=97=A5 (=E6=B0=B4=E6= =9B=9C=E6=97=A5) 15:30
=E5=AE=9B=E5=85=88: pgpool-general@lists.postgresql.org <pgpool-general@= lists.postgresql.org>
=E4=BB=B6=E5=90=8D: SQL query latency when using pgPool (v4.6.2)




Hello,
I am currently testing SQL query performance using PgPool (v4.6.2) as a loa= d balancer, and I am observing approximately 18=E2=80=9320 ms latency betwe= en SQL statements within the same transaction. Execution time on the Postgr= eSQL backend servers is less than 0.5 ms.
It=E2=80=99s important to note that both the application and database serve= rs are located in the same cloud region, with network latency below 1 ms. P= gPool is colocated with the PostgreSQL backend servers.
For example, when executing a transaction containing 10 SQL statements, the= total execution time through pgPool is about 200 ms, as confirmed by both = application and pgPool logs. The delay consistently occurs between the =E2= =80=9CExecute=E2=80=9D and =E2=80=9CParse=E2=80=9D phases. When connecting = directly to the PostgreSQL backends, the same transaction completes in abou= t 10 ms, with roughly 1 ms between SQL statements.
We have tested the following configurations:
- Switched from the extended query protocol to the simple query protocol = =E2=80=94 for some queries this reduced inter-query latency to 2=E2=80=933 = ms, but for others it increased to 30=E2=80=9340 ms due to additional parsi= ng overhead.
- Adjusted various PgPool parameters related to load balancing and connecti= on pooling (e.g., load_balance_mode, statement_level_load_balance, serializ= e_accept, disable_load_balance_on_write) and enabled debug logging, but non= e of these changes brought a significant improvement.
Could you please advise whether there are additional pgPool parameters or t= uning approaches that could help improve throughput and reduce latency in e= xtended query protocol?=C2=A0
Thank you,
Bob
--0000000000002dbc760641bc2be4--