From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, mlw <markw(at)mohawksoft(dot)com> |
Cc: | owensmk(at)earthlink(dot)net, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Connection Pooling, a year later |
Date: | 2001-12-18 11:14:51 |
Message-ID: | 3.0.5.32.20011218191451.00869940@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB SD | 2001-12-18 11:26:06 | Re: [HACKERS] Problem compiling postgres sql --with-tcl |
Previous Message | Lincoln Yeoh | 2001-12-18 11:02:02 | Re: Connection Pooling, a year later |