On 7/30/10 10:37 AM, Kevin Grittner wrote:
> Craig James<craig_james@emolecules.com> wrote:
>
>>> Well, the "if it ain't broke, don't fix it" rule might come into
>>> play here.
>>
>> I should have given one more detail here: We've been the victim
>> of persistent "CPU spikes" that were discussed extensively in
>> postgres-performance. Tom suggested upgrading to 8.4.4, but that
>> can't happen for a couple more months (we're working on it).
>>
>>
> http://archives.postgresql.org/pgsql-performance/2010-04/msg00071.php
>
> Ah, I hadn't connected that thread with this. After rereading that
> thread with the information from this thread in mind, I think what
> you describe on the other thread could well be the "thundering herd"
> problem. Some form of connection pooling could well help.
>
> BTW, I hope you've updated to the latest 8.3.x by now. If not, you
> should expedite that.
Yes, I updated to 8.3.10, partly to see if it would solve this problem.
I'm not clear on how connection pooling would help this problem. I would have 100 lightweight backends, whether they
werepooled or not, always sitting around. Or are you suggesting that I not use Apache::DBI to maintain persistent
connections,and instead rely on the connection pooler to provide fast connect/disconnect from Postgres?
Thanks,
Craig