Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)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
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?
(P.s - academic in my case, unless I try out the latest NetBSD or Linux
on one of my FreeBSD boxes....)
In response to
pgsql-patches by date
|Next:||From: Simon Riggs||Date: 2006-02-14 21:54:12|
|Subject: Re: Patch Submission Guidelines|
|Previous:||From: Andrew Klosterman||Date: 2006-02-14 21:35:28|
|Subject: Re: BUG #2246: Bad malloc interactions: ecpg, openssl|