Re: Separate shared_buffer management process

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Would it be a good idea to have a separate shared buffer process to
> manage the cache? Could such a process take workload off of the main
> backend and improve their performance?

> Just an idea?

I can't recall if this has been discussed on the list, but I know I've
thought about the idea of a background "buffer writer" process that
would simply cycle through the buffer cache and write out dirty buffers
in some low-priority fashion.

The idea is this would reduce the I/O crunch at checkpoint times, as
well as reducing the odds that any foreground backend process would have
to block waiting for I/O before it could recycle a buffer slot to read
in a page it needs. (Perhaps the background writer could be tuned to
preferentially write dirty buffers that are near the tail of the LRU
queue, and thus are likely to get recycled soon.)

In the WAL world, you cannot "write a dirty buffer" until you have
written *and synced* the WAL log as least as far as the LSN of the
buffer you want to write. So a background buffer writer would have
to write WAL buffers as well, and in that context it could find itself
blocking foreground processes. I'm not sure what this does to the
notion of "background I/O". Maybe only buffers whose changes are
already synced in WAL should be eligible for background write.
It needs some thought anyway.

regards, tom lane