Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bgwriter LRU cleaning: we've been going at this all wrong
Date: 2007-09-26 08:31:38
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
This has been saved for the 8.4 release:


Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > I don't really see why it's "overkill".  
> Well I think it may be overkill in that we'll be writing out buffers that
> still have a decent chance of being hit again. Effectively what we'll be doing
> in the approximated LRU queue is writing out any buffer that reaches the 80%
> point down the list. Even if it later gets hit and pulled up to the head
> again.
> I suppose that's not wrong though, the whole idea of the clock sweep is that
> that's precisely the level of precision to which it makes sense to approximate
> the LRU. Ie, that any point in the top 20% is equivalent to any other and when
> we use a buffer we want to promote it to somewhere "near" the head but any
> point in the top 20% is good enough. Then any point in the last 20% should be
> effectively "good enough" too be considered a target buffer to clean as well.
> If we find it's overkill then what we should consider doing is raising
> BM_MAX_USAGE_COUNT. That's effectively tuning the percentage of the lru chain
> that we decide we try to keep clean.
> -- 
>   Gregory Stark
>   EnterpriseDB
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-09-26 08:33:51
Subject: Re: SetBufferCommitInfoNeedsSave and race conditions
Previous:From: Bruce MomjianDate: 2007-09-26 08:26:30
Subject: Re: Background LRU Writer/free list

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group