Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> writes:
>
>>Tom Lane wrote:
>>
>>>Sounds like a recipe for ensuring it never will be tested. What's
>>>needed here is some actual tests, not preparation...
>
>
>>Does the OP have a test scenario that those of us with appropriate OS's
>>could try? Come to think of it, what are the appropriate OS's? (I see
>>NetBSD mentioned so I suppose all the *BSDs, but what others?).
>
>
> The test run by the OP was just pgbench,
Ah - right, missed that sorry.
> which is probably not the
> greatest scenario for showing the benefits of this patch, but at least
> it's neutral ground. You need a situation in which the kernel is under
> memory stress, else early free of disk cache buffers isn't going to make
> any difference whatever --- so choose a pgbench scale factor that makes
> the database noticeably larger than the test machine's RAM. Other than
> that, follow the usual guidelines for producing trustworthy pgbench
> numbers: number of clients smaller than scale factor, number of
> transactions per client at least 1000 or so (to eliminate startup
> transients), repeat test a couple times to make sure numbers are
> reproducible.
>
Thinking about this, presumably any write intensive, multi-user
benchmark would seem to be suitable, so would something like OSDL's
DBT-2 actually be better to try?
Cheers
Mark
(P.s - academic in my case, unless I try out the latest NetBSD or Linux
on one of my FreeBSD boxes....)
