Re: [HACKERS] Clock with Adaptive Replacement - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] Clock with Adaptive Replacement
Date
Msg-id CAH2-WzmgABvbkLf4j8c1tkGQJH0Gt9ahOTYTSm+BVO-0J+U3ug@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Clock with Adaptive Replacement  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Clock with Adaptive Replacement  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Re: [HACKERS] Clock with Adaptive Replacement  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Thu, May 3, 2018 at 12:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, May 2, 2018 at 3:06 PM, Vladimir Sitnikov
> <sitnikov.vladimir@gmail.com> wrote:
>> Sample output can be seen here:
>> https://github.com/vlsi/pgsqlstat/tree/pgsqlio#pgsqlio
>
> Neat.  Not sure what generated this trace, but note this part:
>
> 3271838881374    88205        0        0     1663    16385    16604      0
>  3271840973321     4368        0        0     1663    16385    16604      1
>  3271842680626     4502        0        0     1663    16385    16604      1
>  3271846077927     4173        0        0     1663    16385    16604      1
>
> If we want to avoid artificial inflation of usage counts, that kind of
> thing would be a good place to start -- obviously 4 consecutive
> accesses to the same buffer by the same backend doesn't justify a
> separate usage count bump each time.

I don't have time to check this out just now, but it seems like an
excellent idea. It would be nice if it could be enhanced further, so
you get some idea of what the blocks are without having to decode them
yourself using tools like pageinspect.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped
Next
From: Peter Eisentraut
Date:
Subject: Re: unused_oids script is broken with bsd sed