Re: Connection Pooling, a year later

Does schema support will resolve this discussion ?
If I understand correctly, initial arguments for connection pooling
was restriction in number of persistent connections. it's right in
current postgresql that if one wants keep connection for performance
reason to several databases the total number of connections will
doubled, trippled and so on. But if I understand schema support will
eventually put away these problem because we could keep only one
pool of connections to the *one* database.
Oleg

On Tue, 18 Dec 2001, Don Baccus wrote:

> Bruce Momjian wrote:
>
>
> > Yes, that is assuming you are using PHP.  If you are using something
> > else, you connection pooling in there too.  All those client interfaces
> > reimplementing connection pooling seems like a waste to me.
>
>
> Effective pooling's pretty specific to your environment, though, so any
> general mechanism would have to provide a wide-ranging suite of
> parameters governing the number to pool, how long each handle should
> live, what to do if a handle's released by a client while in the midst
> of a transaction (AOLserver rolls back the transaction, other clients
> might want to do something else, i.e. fire a callback or the like), etc etc.
>
> I think it would be fairly complex and for those high-throughput
> applications already written with client-side pooling no improvement.
>
> And those are the only applications that need it.
>
>
Regards,    Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83