Re: Fork-based version of pgbench - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fork-based version of pgbench
Date
Msg-id 29216.1133507486@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fork-based version of pgbench  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: generalizing the planner knobs
Next
From: Tom Lane
Date:
Subject: Re: Reducing relation locking overhead