From: | xoror(at)infuse(dot)org |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Yutaka tanida <yutaka(at)nonsensecorner(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: lru cache replacement |
Date: | 2003-06-24 15:12:23 |
Message-ID: | Pine.GSO.4.10.10306241705360.10505-100000@taurus |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 24 Jun 2003, Tom Lane wrote:
> Yutaka tanida <yutaka(at)nonsensecorner(dot)com> writes:
> > xoror(at)infuse(dot)org wrote:
> >> does pgbench test with relatively large sequential scans?
>
> > Probably no.
>
> pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be
> very useful for testing a method that's mainly intended to prevent
> seqscans from blowing out the cache.
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Weiping He | 2003-06-24 15:32:30 | Re: a problem with index and user define type |
Previous Message | Rod Taylor | 2003-06-24 15:02:56 | Re: pg_get_triggerdef in pg_dump |