Re: Bug: Buffer cache is not scan resistant

<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>