Re: Connection Pooling, a year later

Поиск
Список
Период
Сортировка
От Michael Owens
Тема Re: Connection Pooling, a year later
Дата
Msg-id E16Gn2K-0005YP-00@gull.prod.itd.earthlink.net
обсуждение исходный текст
Ответ на Re: Connection Pooling, a year later  (Don Baccus <dhogaza@pacifier.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Harvey
Дата:
Сообщение: Re: long ints use for 4-byte entities in ODBC
Следующее
От: "Andrew G. Hammond"
Дата:
Сообщение: Re: Explicit config patch 7.2B4