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