Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> One thing I realized quickly is that there is no natural way in a clock
> >> algorithm to discourage VACUUM from blowing out the cache. I came up
> >> with a slightly ugly idea that's described below. Can anyone do better?
>
> > Uh, is the clock algorithm also sequential-scan proof? Is that
> > something that needs to be done too?
>
> If you can think of a way. I don't see any way to make the algorithm
> itself scan-proof, but if we modified the bufmgr API to tell ReadBuffer
> (or better ReleaseBuffer) that a request came from a seqscan, we could
> do the same thing as for VACUUM. Whether that's good enough isn't
> clear --- for one thing it would kick up the contention for the
> BufFreelistLock, and for another it might mean *too* short a lifetime
> for blocks fetched by seqscan.
If I remember correctly, the ARC system was sequential-scan resistant
_only_ because it split the cache into two parts and let the sequential
scan wipe one cache while the other was for frequently accessed
information and was more immune, and the overhead for a frequent cache
requires too much locking.
One interesting aspect is that we now have only three buffer access
patterns, index pages, random heap lookups via index or ctid, and heap
scans. It would be interesting to control the behavior of each one. For
example, if the sequential scan is larger than the buffer cache, is
there any reason to cache any of it? Should non-sequential scan pages
be kept longer? Can we record on the buffer page how the page was
initially or most recently accessed? The problem with the kernel cache
is that is doesn't know the applicaiton access pattern, but we do so it
seems we can use that information to improve the algorithm.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
