Re: Page replacement algorithm in buffer cache
От | Atri Sharma |
---|---|
Тема | Re: Page replacement algorithm in buffer cache |
Дата | |
Msg-id | CAOeZVifZ89tOtcKeC6C2917sVfSyR3xiMenorg8sNR2+y2W=Wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Page replacement algorithm in buffer cache (Atri Sharma <atri.jiit@gmail.com>) |
Ответы |
Re: Page replacement algorithm in buffer cache
Re: Page replacement algorithm in buffer cache |
Список | pgsql-hackers |
> >> I think that if the initialization of USAGE_COUNT starts at the maximum >> allowed value instead of one, we can have a better solution to this >> problem. > > So what is your idea, if you start at maximum, what we will do for further > accesses to it? I havent chalked out a detailed plan yet, but I think the idea of initializing USAGE_COUNT to maximum value is not at all good. I was just thinking off the top of my head. > Why do you want to give more priority to just loaded page? I just want it to have more chances to stay, rather than being replaced pretty early. This is because, as I said earlier, a new page could be in high demand in near future, which would lead to repeated replacement-bringing in of page and hence cause overheads. >> Another,more complex solution could be to introduce an aging factor This is the one I think would work out best, add an age factor as to the time duration which an entry has spent in the cache along with its usage count. So, what I am proposing here is to add another factor in the clocksweep algorithm when it selects victim pages for replacement. Specifically, the selection of victim pages should be done with the usage_count AND the time spent by the entry in the cache. This would give priority to pages with high accesses and not ignore relatively young pages as well. If a page is not accessed for a long time after it was allocated, it would be the ideal victim for replacement both in terms of USAGE_COUNT as well as age. Regards, Atri -- Regards, Atri l'apprenant
В списке pgsql-hackers по дате отправления: