Re: [HACKERS] Clock with Adaptive Replacement

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: [HACKERS] Clock with Adaptive Replacement
Дата
Msg-id 26561EDF-F1E3-4AB4-9E33-51792EE4DF95@yandex-team.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] Clock with Adaptive Replacement  (Yura Sokolov <funny.falcon@gmail.com>)
Ответы Re: [HACKERS] Clock with Adaptive Replacement  (Yura Sokolov <funny.falcon@gmail.com>)
Список pgsql-hackers

6 мая 2018 г., в 20:38, Yura Sokolov <funny.falcon@gmail.com> написал(а):

I've been playing with logarithmic scale in postgresql roughly year ago.
I didn't found any benefits compared to current code. In fact, it looked
to perform worse than current code.
That is why I didn't wrote about that experiment to pgsql-hackers.
Is there a feature of testgres to benchmark pgbench tps against shared buffer size? Let's request this feature if it is not there :)

But probably I measured in a wrong way. And why I dream to have
real-world traces in hands.

Consider all known to be effective algorithms: 2Q, ARC, Clock-PRO,
CAR, - they all consider buffer "hot" if it has more temporal frequency
in opposite to raw access count. They all mostly ignores spike of usages
during first moments after placement into cache, and moves buffer to hot
if it is accessed at some time after.
These algorithms do not ignore spikes, they ignore spike's amplitude. And this does not mean that amplitude is irrelevant information, even if these algorithms perform almost like Belady's.

Building a complicated heuristics (with a lot of magic numbers) to merge this spikes into one event does not look promising to me. But this is just my superstition, chances are that you can tune your algorithm into serious advancement. But please publish benchmarks, whatever result will be.

Best regards, Andrey Borodin.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: perlcritic and perltidy
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: perlcritic and perltidy