Greg Smith <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate