At 10:57 PM 12/17/01 -0500, 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.
But trying to connect and reconnect to an RDBMS 100 times a sec sounds
broken (plus authentication etc).
I personally think the fix for that should be at the client side. At worst
it should be in an intermediate application (listener). Otherwise it's like
trying to turn a db server into a webserver, quite a bit of work there.
>> My concern is, and do you know, besides the memory used by idle postgres
>> processes, are there any performance reasons why connection pooling a fewer
>> number of processes, would perform better than a larger number of idle
>> persistent processes?
>>
>> Unless it does, I would say that connection pooling is pointless.
>
>No, idle backends take minimal resources.
I'd personally will be happy with a large number of backends then. Probably
more deterministic having everything fully loaded to the max.
Cheerio,
Link.
