Re: Connection Pooling, a year later

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.

In response to

Browse pgsql-hackers by date

  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