| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] add --throttle to pgbench (submission 3) |
| Date: | 2013-05-02 08:25:52 |
| Message-ID: | alpine.DEB.2.02.1305021016530.27669@localhost6.localdomain6 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Greg,
> If you add this to
> https://commitfest.postgresql.org/action/commitfest_view?id=18 I'll review it
> next month.
Ok. Thanks. I just did that.
> 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.
Indeed. It is a good thing that my proposed feature can help in more
situations than my particular need.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Karol Trzcionka | 2013-05-02 09:04:15 | GSOC13 proposal - extend RETURNING syntax |
| Previous Message | Simon Riggs | 2013-05-02 08:04:20 | Re: Recovery target 'immediate' |