From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fork-based version of pgbench |
Date: | 2005-12-02 06:40:06 |
Message-ID: | 87oe40f1dl.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-12-02 06:44:08 | Re: Reducing relation locking overhead |
Previous Message | Joshua D. Drake | 2005-12-02 05:19:10 | Additional Grant/revoke problem |