From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Hannu Krosing" <hannu(at)2ndquadrant(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | "Samuel Gendler" <sgendler(at)ideasculptor(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Need help in performance tuning. |
Date: | 2010-07-14 13:58:23 |
Message-ID: | 4C3D7C2F020000250003353C@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
>> One example where you need a separate connection pool is pooling
>> really large number of connections, which you may want to do on
>> another host than the database itself is running.
>
> Definitely. Often it's best placed on the individual webservers
> that are making requests, each running its own pool.
Each running its own pool? You've just made a case for an
admissions policy based on active database transactions or active
queries (or both) on the server having a benefit when used with this
pooling arrangement. This collection of pools can't know when the
CPUs have enough to keep them busy and adding more will degrade
performance.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-07-14 14:03:26 | Re: Understanding tsearch2 performance |
Previous Message | Ivan Voras | 2010-07-14 13:57:35 | Re: Understanding tsearch2 performance |