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

From Greg Stark
Subject Re: Fork-based version of pgbench
Date
Msg-id 87oe40f1dl.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Fork-based version of pgbench  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fork-based version of pgbench
List pgsql-hackers
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.

I suspect the difference is the same thing you theorised made the difference
before. Namely that they're no longer proceeding in lockstep. The progress is
more random allowing some processes to make more progress than average and
benefit from better, er, well some cache somewhere.

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.


-- 
greg



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Additional Grant/revoke problem
Next
From: Greg Stark
Date:
Subject: Re: Reducing relation locking overhead