Re: Bgwriter LRU cleaning: we've been going at this all wrong

Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> Unless someone else has a burning desire to implement Tom's idea faster
> than me, I should be to build this new implementation myself in the next
> couple of days.

Sure, go for it. I'm going to work next on committing the LDC patch,
but I'll try to avoid modifying any of the code involved in the LRU
scan, so as to minimize merge problems for you. Now that we have a new
plan for this, I think we can just omit any of the parts of the LDC
patch that might have touched that code.

I realized on re-reading that I'd misstated the conditions slightly:
any time the cleaning scan falls behind the clock sweep at all (not
necessarily a whole lap) it should forcibly advance its pointer to the
current sweep position. This would mainly be relevant right at bgwriter
startup, when it's starting from the sweep position and trying to get
ahead; it might easily not be able to, until there's a lull in the
demand for new buffers. (So until that happens, the changed code would
work just the same as now: write the first lru_maxpages dirty buffers
in front of the sweep point.) The main point of this change is that when
there is a lull, the bgwriter will exploit it to get ahead, rather than
sitting on its thumbs as it does today ...

regards, tom lane