Re: Page replacement algorithm in buffer cache

On Thursday, April 04, 2013 6:12 PM Robert Haas wrote:
> On Wed, Apr 3, 2013 at 9:49 PM, Greg Smith <greg(at)2ndquadrant(dot)com>
> wrote:
> > On 4/2/13 11:54 AM, Robert Haas wrote:
> >> But, having said that, I still think the best idea is what Andres
> >> proposed, which pretty much matches my own thoughts: the bgwriter
> >> needs to populate the free list, so that buffer allocations don't
> have
> >> to wait for linear scans of the buffer array.
> >
> > I was hoping this one would make it to a full six years of being on
> the TODO
> > list before it came up again, missed it by a few weeks. The funniest
> part
> > is that Amit even submitted a patch on this theme a few months ago
> without
> > much feedback:
> > http://www.postgresql.org/message-
> id/6C0B27F7206C9E4CA54AE035729E9C382852FF97(at)szxeml509-mbs
> > That stalled where a few things have, on a) needing more regression
> test
> > workloads, and b) wondering just what the deal with large
> shared_buffers
> > setting degrading performance was.
>
> Those are impressive results. I think we should seriously consider
> doing something like that for 9.4. TBH, although more workloads to
> test is always better, I don't think this problem is so difficult that
> we can't have some confidence in a theoretical analysis. If I read
> the original thread correctly (and I haven't looked at the patch
> itself), the proposed patch would actually invalidate buffers before
> putting them on the freelist. That effectively amounts to reducing
> shared_buffers, so workloads that are just on the edge of what can fit
> in shared_buffers will be harmed, and those that benefit incrementally
> from increased shared_buffers will be as well.
>
> What I think we should do instead is collect the buffers that we think
> are evictable and stuff them onto the freelist without invalidating
> them. When a backend allocates from the freelist, it can double-check
> that the buffer still has usage_count 0. The odds should be pretty
> good. But even if we sometimes notice that the buffer has been
> touched again after being put on the freelist, we haven't expended all
> that much extra effort, and that effort happened mostly in the
> background.

If we just put it to freelist, then next time if it get allocated directly
from bufhash table, then who will remove it from freelist
or do you think that, in BufferAlloc, if it gets from bufhash table, then it
should verify if it's in freelist, then remove from freelist.

With Regards,
Amit Kapila.