Re: Design notes for BufMgrLock rewrite

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Design notes for BufMgrLock rewrite
Дата
Msg-id 87bran680o.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Design notes for BufMgrLock rewrite  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Tom Lane wrote:
> > 
> > One thing I realized quickly is that there is no natural way in a clock
> > algorithm to discourage VACUUM from blowing out the cache.  I came up
> > with a slightly ugly idea that's described below.  Can anyone do better?
> 
> Uh, is the clock algorithm also sequential-scan proof?  Is that
> something that needs to be done too?

I think the normal strategy is to make it *always* work the way you made
VACUUM work. That is, it should always enter newly loaded pages with the
"recently used" flag false.

It doesn't necessarily mean they get purged immediately on the next flush, any
other buffer that hasn't been accessed since it was loaded is also a
candidate, but if nothing else accesses it before the clock hand gets to it
then it a candidate.

The only thing that scares me about this is that running a vacuum or
sequential scan could have too much of an effect on non-sequential accesses
like index scans if it forced the hand around so fast that the index scan
didn't have a chance to reuse pages.

-- 
greg



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

Предыдущее
От: Tzahi Fadida
Дата:
Сообщение: Re: Query optimizer 8.0.1 (and 8.0)
Следующее
От: Sibtay Abbas
Дата:
Сообщение: getting oid of function