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(at)candle(dot)pha(dot)pa(dot)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(at)nonsensecorner(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073