Skip site navigation (1) Skip section navigation (2)

Re: Fork-based version of pgbench

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fork-based version of pgbench
Date: 2005-12-02 07:11:26
Message-ID: 29216.1133507486@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> It's not so much that I want to inflate the measurements, as that
>> leaving 10% of the CPU on the table reduces pgbench's usefulness as
>> a way of stress-testing the backend.
> ...
> In any case it seems like there would be cases where each kind of behaviour
> would be useful. It seems likely there would be bugs where the lockstep
> behaviour was useful for testing, and other bugs where the randomized
> behaviour would be useful for testing too.

No, I'm not thinking about bugs at all, but performance stress tests.
As an example, the various context-swap-storm behaviors we've been
chasing over the past year or so cannot arise unless you can get several
processes competing for the same resource at the same time.  If your
test configuration isn't capable of saturating the CPU then you have
a much lower probability of being able to observe such misbehavior.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-02 07:14:37
Subject: Re: Reducing relation locking overhead
Previous:From: Greg StarkDate: 2005-12-02 07:09:49
Subject: Re: generalizing the planner knobs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group