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

From Andrey Borodin
Subject Re: [HACKERS] Clock with Adaptive Replacement
Date
Msg-id FCB1A042-574E-4B91-8ECD-794D169F3C9F@yandex-team.ru
Whole thread Raw
In response to Re: [HACKERS] Clock with Adaptive Replacement  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Clock with Adaptive Replacement  (Юрий Соколов <funny.falcon@gmail.com>)
List pgsql-hackers
> 4 мая 2018 г., в 0:37, Robert Haas <robertmhaas@gmail.com> написал(а):
>
> 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.

Upper in this thread Yura suggested that usages should not create equal bump each time. He effectively suggested log
scaleof usages, thus many consecutive usages will be taken into account but not dramatically more important than just
fewrecent usages. 

Best regards, Andrey Borodin.

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooling
Next
From: Marina Polyakova
Date:
Subject: Re: [HACKERS] path toward faster partition pruning