Re: usleep feature for pgbench

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: usleep feature for pgbench
Date: 2007-07-06 02:58:29
Message-ID: 468DAFD5.30002@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/5/2007 5:30 PM, Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>> I think I've coded it in a way that if one doesn't use the \usleep
>> command at all, it will never even call gettimeofday() and use a NULL
>> timeout in select() as it used to.
>
> Did you check that the observed performance for non-usleep-using scripts
> didn't change? If this extra overhead causes a reduction in reported
> TPS rates it would make it hard to compare older and newer tests.

Given pgbench's unpredictability of results ... lets see.

I ran

dropdb x
createdb x
pgbench -i -s10 x
psql -c 'checkpoint' x
sleep 1
psql -c 'checkpoint' x
pgbench -s10 -c5 -t10000 x
pgbench -s10 -c5 -t10000 x
pgbench -s10 -c5 -t10000 x

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".

>
> Other than that I've got no objection to it.

Will be committed after adjusting the README.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2007-07-06 06:43:38 tsearch2: language or encoding
Previous Message Tom Lane 2007-07-05 23:52:42 enable-integer-datetimes vs datetime hash functions