Re: Free WAL caches on switching segments
От | Mark Kirkwood |
---|---|
Тема | Re: Free WAL caches on switching segments |
Дата | |
Msg-id | 43F250A3.6020304@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: Free WAL caches on switching segments (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Free WAL caches on switching segments
|
Список | pgsql-patches |
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....)
В списке pgsql-patches по дате отправления: