Skip site navigation (1) Skip section navigation (2)

Re: Free WAL caches on switching segments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, daveg <daveg(at)sonic(dot)net>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Free WAL caches on switching segments
Date: 2006-02-14 14:47:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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, 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

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Simon RiggsDate: 2006-02-14 15:10:35
Subject: Re: Free WAL caches on switching segments
Previous:From: Simon RiggsDate: 2006-02-14 12:54:10
Subject: Re: Free WAL caches on switching segments

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group