Re: Connection Pooling, a year later

From: Michael Owens <owensmk(at)earthlink(dot)net>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Connection Pooling, a year later
Date: 2001-12-19 20:28:14
Message-ID: E16Gn2K-0005YP-00@gull.prod.itd.earthlink.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew G. Hammond 2001-12-19 20:41:38 Re: Explicit config patch 7.2B4
Previous Message Tom Lane 2001-12-19 19:58:48 Re: SunOS patch for memcmp()