<p><font size="2">This sounds like a good idea.<br /><br /> - Luke<br /><br /> Msg is shrt cuz m on ma treo<br /><br />
-----OriginalMessage-----<br /> From: Simon Riggs [<a
href="mailto:simon@2ndquadrant.com">mailto:simon@2ndquadrant.com</a>]<br/> Sent: Monday, March 05, 2007 02:37 PM
EasternStandard Time<br /> To: Josh Berkus; Tom Lane; Pavan Deolasee; Mark Kirkwood; Gavin Sherry; Luke Lonergan;
PGSQLHackers; Doug Rady; Sherry Moore<br /> Cc: pgsql-hackers@postgresql.org<br /> Subject: Re: [HACKERS]
Bug:Buffer cache is not scan resistant<br /><br /> On Mon, 2007-03-05 at 10:46 -0800, Josh Berkus wrote:<br /> >
Tom,<br/> ><br /> > > I seem to recall that we've previously discussed the idea of letting the<br /> > >
clocksweep decrement the usage_count before testing for 0, so that a<br /> > > buffer could be reused on the
firstsweep after it was initially used,<br /> > > but that we rejected it as being a bad idea. But at least with
large<br/> > > shared_buffers it doesn't sound like such a bad idea.<br /><br /> > Note, though, that the
currentalgorithm is working very, very well for OLTP<br /> > benchmarks, so we'd want to be careful not to gain
performancein one area at<br /> > the expense of another.<br /><br /> Agreed.<br /><br /> What we should also add to
theanalysis is that this effect only occurs<br /> when only uniform workloads is present, like SeqScan, VACUUM or
COPY.<br/> When you have lots of indexed access the scan workloads don't have as<br /> much effect on the cache
pollutionas we are seeing in these tests.<br /><br /> Itakgaki-san and I were discussing in January the idea of
cache-looping,<br/> whereby a process begins to reuse its own buffers in a ring of ~32<br /> buffers. When we cycle
backround, if usage_count==1 then we assume that<br /> we can reuse that buffer. This avoids cache swamping for read
andwrite<br /> workloads, plus avoids too-frequent WAL writing for VACUUM.<br /><br /> It would be simple to implement
thering buffer and enable/disable it<br /> with a hint StrategyHintCyclicBufferReuse() in a similar manner to the<br />
hintVACUUM provides now.<br /><br /> This would maintain the beneficial behaviour for OLTP, while keeping<br /> data
withinthe L2 cache for DSS and bulk workloads.<br /><br /> --<br /> Simon Riggs <br /> EnterpriseDB <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/><br /><br /><br /></font>
