From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: Atri Sharma <atri.jiit@gmail.com>,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Page replacement algorithm in buffer cache
In-reply-to: 
 <CAMkU=1zpEW-L162uhUJcZ9MKxmRtxNqBFKDQyoaiwr0rc8ZnXg@mail.gmail.com>
References: 
 <CAOeZVic4HikhmzVD=ZP4JY9g8PgpyiQQOXOELWP=kR+=H1Frgg@mail.gmail.com>
	<CAMkU=1zpEW-L162uhUJcZ9MKxmRtxNqBFKDQyoaiwr0rc8ZnXg@mail.gmail.com>
Comments: In-reply-to Jeff Janes <jeff.janes@gmail.com>
	message dated "Sat, 23 Mar 2013 12:29:24 -0700"
Date: Sat, 23 Mar 2013 16:07:42 -0400
Message-ID: <487.1364069262@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Jeff Janes <jeff.janes@gmail.com> writes:
> I'm more convinced in the other direction, new pages should enter with 0
> rather than with 1.  I think that the argument that a new buffer needs to
> be given more of an opportunity to get used again is mostly bogus.

IIRC, the argument for starting at 1 not 0 is that otherwise a new page
might have an infinitesmally small lifespan, if the clock sweep should
reach it just after it gets entered into the buffers.  By starting at
1, the uncertainty in a new page's lifespan runs from 1 to 2 sweep times
not 0 to 1 sweep time.

I think though that this argument only holds water if the buffer didn't
get found via the clock sweep to start with --- otherwise, it ought to
have just about one clock sweep of time before the sweep comes back to
it.  It does apply to buffers coming off the freelist, though.

Thus, if we were to get rid of the freelist then maybe we could change
the starting usage_count ... but whether that's a good idea in itself
is pretty uncertain.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers