Re: Fork-based version of pgbench

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