Bruce Momjian wrote:
> 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.
Yes ... this is one reason why folks like Oracle want to be able to
bypass the kernel 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.
It would be interesting to learn more about the actual hueristic Oracle
uses (straight percents of the buffer cache? Something based on
concurrency? I have no idea). The Oracle folks have got tons and tons
of data on real-world big, busy db installations to draw from when they
investigate such things.
--
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org
