> > That is on our TODO list, at least.
> >
>
> Hmm, on Linux this sort of behavior (skip the pg buffers for sequential
> scans) would have interesting load senstive behavior: since Linux uses
> all not-otherwise in use RAM as buffer cache, if you've got a low-load
> system, even very large tables will be cached. Once other processes start
> competing for RAM, your buffers go away. Bruce, what does xBSD do?
FreeBSD does, NetBSD will soon, not sure about the others. I believe
NetBSD will be tunable because page cache vs. i/o cache is not always
best done with a FIFO setup.
Also, when we pull from the kernel cache we have to read into our shared
buffers; much faster than disk i/o but slower than if they were already
in the cache. For me the idea of doing non-cached sequential scans came
from a Solaris internals book I was reading. I think it will be
possible to mark large sequential scan buffer i/o with lower priority
caching that may help performance. However, if others are also doing
sequential scans of the same table _only_, our normal caching may be
best. As you can see, this gets quite complicated and I am doubtful
there will be a general solution to this problem --- more of a feedback
loop may be the best bet --- determine which sequential scans are wiping
the cache with little other purpose and start not caching them.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
