Re: lru cache replacement

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: xoror(at)infuse(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yutaka tanida <yutaka(at)nonsensecorner(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: lru cache replacement
Date: 2003-06-29 03:37:03
Message-ID: 200306290337.h5T3b3G01670@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

xoror(at)infuse(dot)org wrote:
> > I tried to implement LRU-2 awhile ago, and got discouraged when I
> > couldn't see any performance improvement. But I was using pgbench as
> > the test case, and failed to think about its lack of seqscans.
>
> Yes , lru-2 will behave like LRU under 'normal' load. it will detect
> sequential scans and adapt to it. I think that was why you didn't
> see any substantial gain in cache hits. though I think ARC does a better
> job. LRU-2 also has logaritmic complexity overhead.
>
> The ARC guys have tested with real traces from a Db of a large insurrance
> company and the results were quite encouraging. (a lot of other traces
> where examined as well)
>
> > We could probably resurrect that code for comparison to 2Q, if anyone
> > can devise more interesting benchmark cases to test.
>
> As i stated before, i'm willing to implement ARC and to see how they all
> compare.

Great.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Björklund 2003-06-29 05:40:50 Re: CVS tip compile failure (was Re: Missing array support)
Previous Message Tom Lane 2003-06-29 03:29:55 Re: join_references: variable not in subplan target lists