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