Re: [HACKERS] Clock with Adaptive Replacement

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: [HACKERS] Clock with Adaptive Replacement
Дата
Msg-id FCB1A042-574E-4B91-8ECD-794D169F3C9F@yandex-team.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] Clock with Adaptive Replacement  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Clock with Adaptive Replacement  (Юрий Соколов <funny.falcon@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Built-in connection pooling
Следующее
От: Marina Polyakova
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning