Re: lru cache replacement

Поиск
Список
Период
Сортировка
От xoror@infuse.org
Тема Re: lru cache replacement
Дата
Msg-id Pine.GSO.4.10.10306241705360.10505-100000@taurus
обсуждение исходный текст
Ответ на Re: lru cache replacement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: lru cache replacement  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
On Tue, 24 Jun 2003, Tom Lane wrote:

> Yutaka tanida <yutaka@nonsensecorner.com> writes:
> > xoror@infuse.org wrote:
> >> does pgbench test with relatively large sequential scans?
> 
> > Probably no. 
> 
> pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be
> very useful for testing a method that's mainly intended to prevent
> seqscans from blowing out the cache.
> 
> I tried to implement LRU-2 awhile ago, and got discouraged when I
> couldn't see any performance improvement.  But I was using pgbench as
> the test case, and failed to think about its lack of seqscans.

Yes , lru-2 will behave like LRU under 'normal' load. it will detect
sequential scans and adapt to it. I think that was why you didn't
see any substantial gain in cache hits. though I think ARC does a better
job. LRU-2 also has logaritmic complexity overhead.

The ARC guys have tested with real traces from a Db of a large insurrance
company and the results were quite encouraging. (a lot of other traces
where examined as well)
> We could probably resurrect that code for comparison to 2Q, if anyone
> can devise more interesting benchmark cases to test.

As i stated before, i'm willing to implement ARC and to see how they all
compare. 





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

Предыдущее
От: Brage
Дата:
Сообщение: Week numbers and years
Следующее
От: Jonathan Bartlett
Дата:
Сообщение: Re: [GENERAL] Physical Database Configuration