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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Atri Sharma <atri.jiit@gmail.com>
Cc: Peter Geoghegan <pg@heroku.com>, Greg Stark <stark@mit.edu>, Ants Aasma <ants@cybertec.at>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-04-18T19:37:36Z
Lists: pgsql-hackers
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.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


Commits

  1. Replace the BufMgrLock with separate locks on the lookup hashtable and