One more thing: the L2 is invalidated when re-written from the kernel IO cache, 
but the pages addressed in L2 retain their values when 'writeen thru' which 
allows the new data to be re-used up the executor chain.

- Luke

Msg is shrt cuz m on ma treo

 -----Original Message-----
From:   Tom Lane [mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 04, 2007 08:36 PM Eastern Standard Time
To:     Luke Lonergan
Cc:     PGSQL Hackers; Doug Rady; Sherry Moore
Subject:        Re: [HACKERS] Bug: Buffer cache is not scan resistant

"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> The issue is summarized like this: the buffer cache in PGSQL is not "scan
> resistant" as advertised.

Sure it is.  As near as I can tell, your real complaint is that the
bufmgr doesn't attempt to limit its usage footprint to fit in L2 cache;
which is hardly surprising considering it doesn't know the size of L2
cache.  That's not a consideration that we've ever taken into account.

I'm also less than convinced that it'd be helpful for a big seqscan:
won't reading a new disk page into memory via DMA cause that memory to
get flushed from the processor cache anyway?  I wonder whether your
numbers are explained by some other consideration than you think.

                        regards, tom lane

Reply via email to