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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(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
