Horton

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

Atri Sharma <atri.jiit@gmail.com>

View thread View on postgr.es
From: Atri Sharma <atri.jiit@gmail.com>
To: Albe Laurenz <laurenz.albe@wien.gv.at>
Cc: "Jason Petersen *EXTERN*" <jason@citusdata.com>, Bruce Momjian <bruce@momjian.us>, Peter Geoghegan <pg@heroku.com>, Greg Stark <stark@mit.edu>, Ants Aasma <ants@cybertec.at>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-04-22T07:32:03Z
Lists: pgsql-hackers 
On Tue, Apr 22, 2014 at 12:59 PM, Albe Laurenz <laurenz.albe@wien.gv.at>wrote:

> Jason Petersen wrote:
> > Yes, we obviously want a virtual clock. Focusing on the use of
> gettimeofday seems silly to me: it was
> > something quick for the prototype.
> >
> > The problem with the clocksweeps is they don’t actually track the
> progression of “time” within the
> > PostgreSQL system.
>
> Would it make sense to just cache the result of the latest gettimeofday()
> call
> and use that as an approximation for wall time?
> The busier the system is, the more accurate that should be.
>
>
That sounds...risky. How will the invalidation/updation of the cache work?

How will we track the time window in which the cached value is still valid
and applicable?

My first thoughts only. I may be missing the point though.

Regards,

Atri



-- 
Regards,

Atri
*l'apprenant*

Commits

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