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

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Bgwriter LRU cleaning: we've been going at this all wrong
Дата
Msg-id 87y7i5xwtp.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на 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  (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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Bgwriter LRU cleaning: we've been going at this all wrong
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bgwriter LRU cleaning: we've been going at this all wrong