Re: usleep feature for pgbench

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: usleep feature for pgbench
Date: 2007-07-06 07:46:10
Message-ID: Pine.GSO.4.64.0707060323450.17749@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 5 Jul 2007, Jan Wieck wrote:

> Original pgbench reported 39, 37 and 33 TPS. Having my patch applied it
> reported 40, 38 and 33 TPS. Inserting a "\usleep 1" after the update to
> accounts of a default equivalent script changed those numbers to 40, 37 and
> 33. I interpret that as "does not change observed performance".

Tell you what: put your work into a patch, send it to the list, and I'll
test that it doesn't degrade results for you. If your pgbench results are
in the <40 TPS range even with that low of a scale, you're not in a
position to tell whether it has a negative performance impact. That
select statement you're fiddling with can turn into a bottleneck at high
client loads, and from your description I can't tell if you've made that
worse, but you'll never see it unless you're pushing, say,
>1000 TPS and >50 clients. Also: 3 pgbench results at one client load
is quite a bit short of proving no impact on performance; I'll queue up 50
or so, which is where I start to trust results from that unruly tool.

This is actually a feature I'd be kind of interested to have, because it
would allow you to pass two (or more) script files to pgbench and adjust
the transaction mix. What happens when you do that right now is that
inevitably all the clients get blocked at once on whatever the hardest to
execute transaction is, and the results are kind of deceptive as a result.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2007-07-06 07:51:02 Re: script binaries renaming
Previous Message Tom Lane 2007-07-06 06:57:34 Re: tsearch2: language or encoding