Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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. 


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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group