Re: [PATCH] add --throttle option to pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] add --throttle option to pgbench
Date: 2013-04-29 18:08:40
Message-ID: alpine.DEB.2.02.1304291945540.7344@localhost6.localdomain6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Jeff,

> While I don't understand the part about his laptop battery, I think that
> there is a good use case for this. If you are looking at latency
> distributions or spikes, you probably want to see what they are like with a
> load which is like the one you expect having, not the load which is the
> highest possible. Although for this use case you would almost surely be
> using custom transaction files, not default ones, so I think you could just
> use \sleep. However, I don't know if there is an easy way to dynamically
> adjust the sleep value by subtracting off the overhead time and randomizing
> it a bit, like is done here.

Indeed, my thoughts:-) Having regularly (\sleep n) or uniformly
distributed (\sleep :random_value) is not very realistic, and I would have
to do some measures to find the right value for a target load.

> It does seem to me that we should Poissonize the throttle time, then
> subtract the average overhead, rather than Poissonizing the difference.

I actually thought about doing it the way you suggested, because it was
"right". However I did not do it, because if the Poisson gives, possibly
quite frequently, a time below the transaction time, one ends up with an
artificial sequence of stuck transactions, as a client cannot start the
second transaction while the previous one is not finished, and this does
not seem realistic. To really do that more cleanly, it would require
distributing the events between clients, so having some kind of
coordination between clients, which would really be another test
application. Having an approximation of that seemed good enough for my
purpose.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-04-29 18:12:54 Re: Fixing statistics problem related to vacuum truncation termination
Previous Message Josh Berkus 2013-04-29 17:50:02 Re: ALTER DEFAULT PRIVILEGES FOR ROLE is broken