Re: Bgwriter LRU cleaning: we've been going at this all wrong - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bgwriter LRU cleaning: we've been going at this all wrong
Date
Msg-id 537.1182897112@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Greg Smith <gsmith@gregsmith.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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Bugtraq: Having Fun With PostgreSQL
Next
From: Heikki Linnakangas
Date:
Subject: Re: Bgwriter LRU cleaning: we've been going at this all wrong