Re: Page replacement algorithm in buffer cache - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Page replacement algorithm in buffer cache
Date
Msg-id 29209.1365036099@sss.pgh.pa.us
Whole thread Raw
In response to Re: Page replacement algorithm in buffer cache  (Greg Stark <stark@mit.edu>)
Responses Re: Page replacement algorithm in buffer cache
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> I'm still skeptical about the idea of a "freelist". That just seems like a
> terrible point of contention. However perhaps that's because I'm picturing
> an LRU linked list. Perhaps the right thing is to maintain a pool of
> buffers in some less contention-prone data structure which lets each
> backend pick buffers out more or less independently of the others.

I think the original vision of the clock sweep algorithm included the
idea that different backends could be running the sweep over different
parts of the buffer ring concurrently.  If we could get rid of the need
to serialize that activity, it'd pretty much eliminate the bottleneck
I should think.  The problem is how to manage it to ensure that (a)
backends aren't actually contending on the same buffers as they do this,
and (b) there's a reasonably fair rate of usage_count decrements for
each buffer, rather than possibly everybody ganging up on the same area
sometimes.  Thoughts?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: corrupt pages detected by enabling checksums
Next
From: Tom Lane
Date:
Subject: Re: corrupt pages detected by enabling checksums