Re: Clock sweep not caching enough B-Tree leaf pages?

On Thu, Apr 17, 2014 at 2:16 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
>> 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.
>
> The trouble is that we're ending up "hiding" the information from the OS
> about the frequency of utilization of that page. You have a good point
> and we wouldn't want to do this for pages that are just accessed once or
> similar, but perhaps just mark a page that's reached the 'max' as having
> been 'hot' and then, for those pages, advise the OS that while we're
> under pressure and need to push this page out, it was once pretty hottly
> used and therefore we may want it again soon.
>
> For pages that never reach the 'max' level, we wouldn't do anything on
> the assumption that those were only temporairly needed.

yeah -- the thing is, we are already too spendy already on
supplemental write i/o (hint bits, visible bits, freezing, etc) and
likely not worth it to throw something else on the pile unless the
page is already dirty; the medium term trend in storage is that read
vs write performance is becoming increasingly asymmetric, particularly
on the random side so it's very unlikely to balance out.

merlin