Re: usleep feature for pgbench - Mailing list pgsql-hackers

From Greg Smith
Subject Re: usleep feature for pgbench
Date
Msg-id Pine.GSO.4.64.0707060323450.17749@westnet.com
Whole thread Raw
In response to Re: usleep feature for pgbench  (Jan Wieck <JanWieck@Yahoo.com>)
List 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@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: tsearch2: language or encoding
Next
From: Greg Smith
Date:
Subject: Re: Bgwriter strategies