Re: lru cache replacement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lru cache replacement
Date
Msg-id 19212.1056464829@sss.pgh.pa.us
Whole thread Raw
In response to Re: lru cache replacement  (Yutaka tanida <yutaka@nonsensecorner.com>)
Responses Re: lru cache replacement  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Re: lru cache replacement  (Yutaka tanida <yutaka@nonsensecorner.com>)
Re: lru cache replacement  (xoror@infuse.org)
Re: lru cache replacement  (Yutaka tanida <yutaka@hi-net.zaq.ne.jp>)
List pgsql-hackers
Yutaka tanida <yutaka@nonsensecorner.com> writes:
> xoror@infuse.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.

We could probably resurrect that code for comparison to 2Q, if anyone
can devise more interesting benchmark cases to test.

BTW, when you were running your test case, what shared_buffers did you
use?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: interval's and printing...
Next
From: Bruce Momjian
Date:
Subject: Re: interval's and printing...