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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Bgwriter LRU cleaning: we've been going at this all wrong
Дата
Msg-id 200803112046.m2BKkZM00474@momjian.us
обсуждение исходный текст
Ответ на Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Added to TODO:


* Consider wither increasing BM_MAX_USAGE_COUNT improves performance
 http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php



---------------------------------------------------------------------------

Gregory Stark wrote:
> 
> "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
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Autovacuum vs statement_timeout
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Restartable signals 'n all that