Re: lru cache replacement

Поиск
Список
Период
Сортировка
От xoror@infuse.org
Тема Re: lru cache replacement
Дата
Msg-id Pine.GSO.4.10.10306241309510.7451-100000@taurus
обсуждение исходный текст
Список pgsql-hackers
On Tue, 24 Jun 2003 xoror@infuse.org wrote:

> I was researching on cache replacement strategy as well. 2Q has one
> disadvantage see this exellent paper:
> http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper
> "ARC: A Self-Tuning, Low Overhead Replacement Cache" for theory and "One
> Up on LRU" for implementation details. ARC requires no tuning and can
> switch fast between chaging patterns. Best of all is it is resistant to a
> "sequential scan" pattern. and i think it's even easier to implement then
> 2q :) 
> 
> does pgbench test with relatively large sequential scans?
> 

BTW, i'm also willing to implement ARC for pgsql if you guys also think
it's a better algoritm. We will no longer have to tweak parameters like
Kin, Kout. ARC also uses 2 buffers like 2q.  



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: join_references: variable not in subplan target lists
Следующее
От: "Enke, Michael"
Дата:
Сообщение: Re: again: Bug #943: Server-Encoding from EUC_TW