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
Дата
Msg-id 17390.1182955134@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Greg Smith <gsmith@gregsmith.com>)
Ответы Re: Bgwriter LRU cleaning: we've been going at this all wrong  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Greg Smith <gsmith@gregsmith.com> writes:
> What may need to happen here is to add Tom's approach, but perhaps 
> restrain it using the current auto-tuning LRU patch's method of estimating 
> how many clean buffers are needed in the near future.  Particularly on 
> large buffer caches, the idea of getting so far ahead of the sweep that 
> you're looping all the away around and following right behind the clock 
> sweep point may be overkill, but I think it will help enormously on 
> smaller caches that are often very dirty.

I don't really see why it's "overkill".  My assumption is that it won't
really be hard to lap the clock sweep during startup --- most likely,
on its first iteration the bgwriter will see all of the cache as not a
candidate for writing (invalid, or at worst just touched) and will be
caught up before any real load materializes.  So the question is not can
it get into that state, it's whether it can stay there under load.
        regards, tom lane


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

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