On Wed, Apr 3, 2013 at 3:00 PM, Robert Haas
<robertmhaas@gmail.com> wrote:
The main hesitation I've had about actually implementing such a scheme
is that I find it a bit unappealing to have a background process
dedicated to just this. But maybe it could be combined with some of
the other ideas presented here. Perhaps we should have one process
that scans the buffer arena and populates the freelists; as a side
effect, if it runs across a dirty buffer, it kicks it over to the
process described in the previous paragraph (which could still, also,
absorb requests from other backends using buffer access strategies).
Then we'd end up with nothing that looks exactly like the background
writer we have now, but maybe no one would miss it.
I think the general pattern of development has led in the opposite direction. Every time there's been one daemon responsible for two things it's ended up causing contorted code and difficult to tune behaviours and we've ended up splitting the two.
In particular in this case it seems like an especially poor choice. In the time one buffer write might take the entire freelist might empty out. I could easily imagine this happening *every* time a write I/O happens. It seems more likely that you'll need multiple processes running the buffer cleaning to keep up with a decent I/O subsystem.
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.
--
greg