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
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....)
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
