Re: Connection Pooling, a year later
От | Lincoln Yeoh |
---|---|
Тема | Re: Connection Pooling, a year later |
Дата | |
Msg-id | 3.0.5.32.20011218191451.00869940@192.228.128.13 обсуждение исходный текст |
Ответ на | Re: Connection Pooling, a year later (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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.
В списке pgsql-hackers по дате отправления: