<p><font size="2">When we instrument the page selections made within the buffer cache, they are sequential and span the
entireaddress space of the cache.<br /><br /> With respect to whether it's L2, it's a conclusion based on the
experimentalresults. It's not the TLB, as we also tested for the 512 entries for each L2.<br /><br /> One thing I left
outof the previous post: the difference between fast and slow behavior was that in the fast case, the buffer selection
alternatedbetween two buffer pages. This was the case only when the preceding statement was a SELECT and the statement
wasVACUUM.<br /><br /> - Luke<br /><br /> Msg is shrt cuz m on ma treo<br /><br /> -----Original Message-----<br />
From: Tom Lane [<a href="mailto:tgl@sss.pgh.pa.us">mailto:tgl@sss.pgh.pa.us</a>]<br /> Sent: Sunday, March 04, 2007
08:36PM Eastern Standard 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>
