| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | David Kerr <dmk(at)mr-paradox(dot)net>, pgsql-performance(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: pgbench could not send data to client: Broken pipe |
| Date: | 2010-09-09 18:07:22 |
| Message-ID: | 4C89225A.1080504@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Kevin Grittner wrote:
> In my experience you can expect the response time benefit of
> reducing the size of your connection pool to match available
> resources to be more noticeable than the throughput improvements.
> This directly contradicts many people's intuition, revealing the
> downside of "gut feel".
>
This is why I focused on showing there won't actually be a significant
throughput reduction, because that part is the most counterintuitive I
think. Accurately modeling the latency improvements of pooling requires
much harder math, and it depends quite a bit on whether incoming traffic
is even or in bursts. Easier in many cases to just swallow expectations
and estimates and just try it instead.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mason Harding | 2010-09-10 22:35:17 | Slow SQL lookup due to every field being listed in SORT KEY |
| Previous Message | Kevin Grittner | 2010-09-09 17:24:17 | Re: pgbench could not send data to client: Broken pipe |