From: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, 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 14:54:51 |
Message-ID: | 1279119291.3888.5.camel@hvost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, 2010-07-14 at 08:58 -0500, Kevin Grittner wrote:
> 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.
I guess this setup is for OLTP load (read "lots of short transactions
with low timeout limits"), where you can just open 2-5 connections per
CPU for mostly-in-memory database, maybe a little more when disk
accesses are involved. If you have more, then they just wait a few
milliseconds, if you have less, you don't have anything else to run
anyway.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-07-14 15:16:56 | Re: Understanding tsearch2 performance |
Previous Message | valgog | 2010-07-14 14:49:50 | Re: Queries with conditions using bitand operator |