Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> 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....)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to