From: Amit Kapila <amit.kapila@huawei.com>
To: 'Atri Sharma' <atri.jiit@gmail.com>
Cc: 'Pg Hackers' <pgsql-hackers@postgresql.org>
Subject: Re: Page replacement algorithm in buffer cache
Date: Fri, 22 Mar 2013 16:28:51 +0530
Message-ID: <007901ce26ec$3d8f9380$b8aeba80$@kapila@huawei.com> (raw)
In-Reply-To: <CAOeZVifZ89tOtcKeC6C2917sVfSyR3xiMenorg8sNR2+y2W=Wg@mail.gmail.com>
References: <CAOeZVic4HikhmzVD=ZP4JY9g8PgpyiQQOXOELWP=kR+=H1Frgg@mail.gmail.com>
<514bf302.84d5440a.43f2.ffffe411SMTPIN_ADDED_BROKEN@mx.google.com>
<08BBC126-D375-4743-B9A6-D1320D05D5C7@gmail.com>
<514c3395.487a420a.28d1.764eSMTPIN_ADDED_BROKEN@mx.google.com>
<CAOeZVifZ89tOtcKeC6C2917sVfSyR3xiMenorg8sNR2+y2W=Wg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Friday, March 22, 2013 4:16 PM Atri Sharma wrote:
> >
> >> 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.
What would you do if the only young page has usage count zero during second
sweep.
I don't think introducing another factor along with usage count would do any
much help.
Have you encountered any such workload very relatively young pages are
getting victimized
and the same is causing performance issues?
With Regards,
Amit Kapila.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: amit.kapila@huawei.com, atri.jiit@gmail.com
Subject: Re: Page replacement algorithm in buffer cache
In-Reply-To: <007901ce26ec$3d8f9380$b8aeba80$@kapila@huawei.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox