Jeff Janes <jeff.janes@gmail.com> writes:
> On Wed, May 23, 2012 at 11:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm ... ISTM that that was discussed back when we instituted buffer
>> usage counts, and rejected on the grounds that a newly-read buffer could
>> then have negligible life expectancy. �The clock sweep might be just
>> about to pass over it.
> I guess that could be the case if the buffer just came off of the
> linked list, but that situation is very rare in general use (and the
> sweep hand wouldn't be moving at all until the linked list is empty).
> If it were allocated through the clock, then the sweep hand should
> have just passed over it and so is unlikely to be just about to pass
> over it again.
Hmm ... that's true as long as we have one central clock sweep. With
the nearby discussion of per-backend sweeps I'm less sure that I believe
it. Still, you might be right that it's worth experimenting with to see
if the average clock sweep distance can be shortened.
So, back to the discussion of what would make acceptable test case(s)
for this. You might look back at the 2005 discussions to see what we
were using at the time of the last major rejiggering in this area.
I concur with your point that we should look at cases where the bulk
of the database fits in kernel disk buffers but not shared_buffers.
regards, tom lane
