From: | xoror(at)infuse(dot)org |
---|---|
To: | pgman(at)candle(dot)pha(dot)pa(dot)us |
Cc: | yutaka(at)nonsensecorner(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: lru cache replacement |
Date: | 2003-06-24 11:13:27 |
Message-ID: | Pine.GSO.4.10.10306241309510.7451-100000@taurus |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 24 Jun 2003 xoror(at)infuse(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Tishler | 2003-06-24 12:09:24 | Re: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure |
Previous Message | Devrim GUNDUZ | 2003-06-24 10:53:56 | .pot files are unavailable (?) |