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

From Gregory Stark
Subject Re: Bgwriter LRU cleaning: we've been going at this all wrong
Date
Msg-id 87y7i5xwtp.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Bruce Momjian <bruce@momjian.us>)
Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.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          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bgwriter LRU cleaning: we've been going at this all wrong
Next
From: Tom Lane
Date:
Subject: Re: Bgwriter LRU cleaning: we've been going at this all wrong