From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] add --throttle to pgbench (submission 3) |
Date: | 2013-05-01 16:56:06 |
Message-ID: | 51814926.7030907@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/1/13 4:57 AM, Fabien COELHO wrote:
> The use case of the option is to be able to generate a continuous gentle
> load for functional tests, eg in a practice session with students or for
> testing features on a laptop.
If you add this to
https://commitfest.postgresql.org/action/commitfest_view?id=18 I'll
review it next month. I have a lot of use cases for a pgbench that
doesn't just run at 100% all the time. I had tried to simulate
something with simple sleep calls, but I realized it was going to take a
stronger math basis to do the job well.
The situations where I expect this to be useful all require collecting
latency data and then both plotting it and doing some statistical
analysis. pgbench-tools computes worst-case and 90th percentile latency
for example, along with the graph over time. There's a useful concept
that some of the official TPC tests have: how high can you get the
throughput while still keeping the latency within certain parameters.
Right now we have no way to simulate that. What we see with write-heavy
pgbench is that latency goes crazy (>60 second commits sometimes) if all
you do is hit the server with maximum throughput. That's interesting,
but it's not necessarily relevant in many cases.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-05-01 17:02:20 | Re: corrupt pages detected by enabling checksums |
Previous Message | Joshua D. Drake | 2013-05-01 16:33:23 | Re: Documentation epub format |