On May 30, Rick Otten modulated:
> If your clients are keeping persistent connections open to the
> database, and the latency you are experiencing is within the
> transaction itself, you might look at disk I/O for your WAL (write
> ahead logs) and take a closer look at WAL and checkpoint tuning.
>
On Wed, May 24, 2017 at 04:17:30PM -0500, Justin Pryzby wrote:
> We got bitten again by what appears to be the same issue I reported (perhaps
> poorly) here:
> https://www.postgresql.org/message-id/20170326193344.GS31628%40telsasoft.com
> I'm diagnosing a bad estimate/plan due to excessively high
Establishing a connection with a PostgreSQL database is a very expensive
process on the database server. On the other hand, establishing a
connection with pgbouncer is very fast.Offloading the connection
management to pgbouncer can significantly reduce the connection set up time.
I've found
Hi Rick thanks for the reply.
Our aim is to minimise latency hence we have a dedicated 1:1 relationship
between the client and the server. If I use connection pooling surely this
introduced latency – getting a server from the pool establishing the connection?
Am I missing something?
From: Ric
