Re: 2Q implementaion for PostgreSQL buffer replacement.

OK, thanks. I will remove it from the queue, and someone suggested a
different algorithm today:

> 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 :)


---------------------------------------------------------------------------

Yutaka tanida wrote:
> 
> On Mon, 23 Jun 2003 23:49:17 -0400 (EDT)
> Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> 
> > 
> > Looks good to me --- we will include it in 7.4.
> 
> Thanks.But please note it is not completed yet. I must implement more ,
> and move configurable parameter to postgresql.conf file.
> 
> -- 
> Yutaka tanida <yutaka@nonsensecorner.com>
> http://www.nonsensecorner.com/
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073