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*
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? |