On Thu, Apr 17, 2014 at 2:00 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Merlin Moncure (mmoncure@gmail.com) wrote:
>> I doubt that's necessary though -- if the postgres caching algorithm
>> improves such that there is a better tendency for hot pages to stay in
>> s_b, Eventually the O/S will deschedule the page for something else
>> that needs it. In other words, otherwise preventable double
>> buffering is really a measurement of bad eviction policy because it
>> manifests in volatility of frequency accessed pages.
>
> I wonder if it would help to actually tell the OS to read in buffers
> that we're *evicting*... On the general notion that if the OS already
> has them buffered then it's almost a no-op, and if it doesn't and it's
> actually a 'hot' buffer that we're gonna need again shortly, the OS will
> have it.
>
> In other words, try to make the OS more like a secondary cache to ours
> by encouraging it to cache things we're evicting.
I don't think this would work unless we would keep some kind of
tracking information on the page itself which seems not worth a write
operation to do (maybe if the page is dirtied it could be snuck in
there though...). IOW, it would only make sense to do this if we knew
that this page was likely to be read in again. This might be true in
general on particular workloads but is probably a pretty flimsy
assumption without supporting evidence; probably better to let the O/S
deal with it.
merlin
