When we instrument the page selections made within the buffer cache, they are
sequential and span the entire address space of the cache.
With respect to whether it's L2, it's a conclusion based on the experimental
results. It's not the TLB, as we also tested for the 512 entries for each L2.
One thing I left out of the previous post: the difference between fast and slow
behavior was that in the fast case, the buffer selection alternated between two
buffer pages. This was the case only when the preceding statement was a SELECT
and the statement was VACUUM.
Msg is shrt cuz m on ma treo
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