<p><font size="2">One more thing: the L2 is invalidated when re-written from the kernel IO cache, but the pages
addressedin L2 retain their values when 'writeen thru' which allows the new data to be re-used up the executor
chain.<br/><br /> - Luke<br /><br /> Msg is shrt cuz m on ma treo<br /><br /> -----Original Message-----<br /> From:
TomLane [<a href="mailto:tgl@sss.pgh.pa.us">mailto:tgl@sss.pgh.pa.us</a>]<br /> Sent: Sunday, March 04, 2007 08:36 PM
EasternStandard Time<br /> To: Luke Lonergan<br /> Cc: PGSQL Hackers; Doug Rady; Sherry Moore<br />
Subject: Re: [HACKERS] Bug: Buffer cache is not scan resistant<br /><br /> "Luke Lonergan"
<llonergan@greenplum.com>writes:<br /> > The issue is summarized like this: the buffer cache in PGSQL is not
"scan<br/> > resistant" as advertised.<br /><br /> Sure it is. As near as I can tell, your real complaint is that
the<br/> bufmgr doesn't attempt to limit its usage footprint to fit in L2 cache;<br /> which is hardly surprising
consideringit doesn't know the size of L2<br /> cache. That's not a consideration that we've ever taken into
account.<br/><br /> I'm also less than convinced that it'd be helpful for a big seqscan:<br /> won't reading a new disk
pageinto memory via DMA cause that memory to<br /> get flushed from the processor cache anyway? I wonder whether
your<br/> numbers are explained by some other consideration than you think.<br /><br />
regards,tom lane<br /><br /></font>