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

On Sat, Apr 19, 2014 at 1:07 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, Apr 18, 2014 at 04:46:31PM +0530, Atri Sharma wrote:
> > This can be changed by introducing an ageing factor that sees how much
> time the
> > current buffer has spend in shared buffers. If the time that the buffer
> has
> > spent is large enough (relatively) and it is not hot currently, that
> means it
> > has had its chance and can be evicted. This shall save the new page (3)
> from
> > being evicted since it's time in shared buffers shall not be high enough
> to
> > mandate eviction and it shall be given more chances.
> >
> > Since gettimeofday() is an expensive call and hence cannot be done in
> the tight
> > loop, we can count the number of clocksweeps the current buffer has seen
> > (rather, survived). This shall give us a rough idea of the estimate of
> the
> > relative age of the buffer.
>
> Counting clock sweeps is an intersting idea. I think one concern was
> tracking hot buffers in cases where there is no memory pressure, and
> hence the clock sweep isn't running --- I am not sure how this would
> help in that case.
>
>
I feel that if there is no memory pressure, frankly it doesnt matter much
about what gets out and what not. The case I am specifically targeting is
when the clocksweep gets to move about a lot i.e. high memory pressure
workloads. Of course, I may be totally wrong here.

One thing that I discussed with Merlin offline and am now concerned about
is how will the actual eviction work. We cannot traverse the entire list
and then find all the buffers with refcount 0 and then do another traversal
to find the oldest one.

Any thoughts there would be appreciated.

Regards,

Atri

--
Regards,

Atri
*l'apprenant*