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

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Jason Petersen <jason(at)citusdata(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Ants Aasma <ants(at)cybertec(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?
Date: 2014-04-18 20:14:42
Message-ID: CAOeZVicoC9xpYKwa2Emn7RJRU3jqbWUvMRXbAqMp5UBN-J3qHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
>
> What’s wrong with using a transaction number or some similar sequence? It
> would accurately track “age” in the sense we care about: how long ago in
> “units of real work being done by the DB” something was added.
>
>
>
Well, AIUI, we only need the 'relative' age of buffers in relation to the
youngest buffer present. So, the guy who has seen the maximum amount of
clocksweeps is the guy who has been around the most.

I do not see a need for an accurate estimate of the time spent in the
buffer for any purpose right now. It may be useful in the future though.

How do you get the transaction ID? By accessing a tuple on the page and
reading it's XMIN?

Regards,

Atri

--
Regards,

Atri
*l'apprenant*

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-04-18 20:26:22 Re: Clock sweep not caching enough B-Tree leaf pages?
Previous Message Jason Petersen 2014-04-18 20:11:04 Re: Clock sweep not caching enough B-Tree leaf pages?