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:03:39 +0530
Message-ID: <007801ce26e8$b86e0810$294a1830$@kapila@huawei.com> (raw)
In-Reply-To: <08BBC126-D375-4743-B9A6-D1320D05D5C7@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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Friday, March 22, 2013 12:00 PM Atri Sharma wrote:
>
>
> Sent from my iPad
>
> On 22-Mar-2013, at 11:28, Amit Kapila <amit.kapila@huawei.com> wrote:
>
> > On Friday, March 22, 2013 10:22 AM Atri Sharma wrote:
> >> Hello all,
> >>
> >> Sorry if this is a naive question.
> >>
> >> I was going through Greg Smith's slides on buffer
> >>
> cache(http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCac
> >> he.pdf).
> >> When going through the page replacement algorithm that we use i.e.
> >> clocksweep algorithm, I felt a potential problem in our current
> >> system.
> >>
> >> Specifically, when a new entry is allocated in the buffer, it's
> >> USAGE_COUNT is set to 1. On each sweep of the algorithm, the
> >> USAGE_COUNT is decremented and an entry whose USAGE_COUNT becomes
> >> zero is replaced.
> >
> > Yes, it is replaced but in the next clock sweep pass, not immediately
> after
> > making 0.
> > So till the time of next pass if nobody accesses the buffer and all
> other
> > buffers have higher count, it can be replaced.
> > Also the buffer, it has returned for which the usage count becomes 1,
> it
> > will come to reduce the usage count only in next pass.
> > So in whole, I think it needs 2 passes for a freshly returned buffer
> to be
> > re-used incase no one uses it again.
> >
> > With Regards,
> > Amit Kapila.
> >
>
> Hmm,so in the second pass,it gets replaced,right?
Yes.
> 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?
Why do you want to give more priority to just loaded page?
> Another,more complex solution could be to introduce an ageing factor as
> well.
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: <007801ce26e8$b86e0810$294a1830$@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