Re: Connection Pooling, a year later - Mailing list pgsql-hackers

From Michael Owens
Subject Re: Connection Pooling, a year later
Date
Msg-id E16Gn2K-0005YP-00@gull.prod.itd.earthlink.net
Whole thread Raw
In response to Re: Connection Pooling, a year later  (Don Baccus <dhogaza@pacifier.com>)
List pgsql-hackers
On Wednesday 19 December 2001 01:04 pm, Don Baccus wrote:


> The general idea is that you grab a handle and hold onto it until you're
> done.  This makes the above scenario impossible.
>
> Forgetting to commit or rollback before relenquishing the handle is
> another scenario that can lead to problems but that's already been
> discussed in detail.

But then the shared connection is unshared, sitting idle while the client 
works in between calls, thus introducing idle time among a fixed number of 
connections. The server is doing less than it could.

I agree that this connection pool has improved things in eliminating backend 
startup time. But idle time still exists for the clients performing multiple 
calls, proportional to the product of the number of multiple call clients and 
the number of calls they make, plus the idle time between them.

However this probably only ever happens on update. Inserts and selects can be 
done in one call. And, I suppose updates comprise only a small fraction of 
the requests sent to the database. Even then, you can probably eliminate some 
multiple calls by using things such as procedures.

Factoring all that in, you can probably do as well by optimizing your 
particular database/application than by writing code.

I relent. Thanks for your thoughts.


pgsql-hackers by date:

Previous
From: Peter Harvey
Date:
Subject: Re: long ints use for 4-byte entities in ODBC
Next
From: "Andrew G. Hammond"
Date:
Subject: Re: Explicit config patch 7.2B4