Re: [HACKERS] lru cache replacement

2003-06-28 Thread Bruce Momjian
[EMAIL PROTECTED] 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 w

Re: [HACKERS] lru cache replacement

2003-06-28 Thread Yutaka tanida
On Tue, 24 Jun 2003 10:27:09 -0400 Tom Lane <[EMAIL PROTECTED]> 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. How about cache hit

Re: [HACKERS] lru cache replacement

2003-06-28 Thread xoror
On Tue, 24 Jun 2003, Tom Lane wrote: > Yutaka tanida <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] 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

Re: [HACKERS] lru cache replacement

2003-06-28 Thread xoror
On Tue, 24 Jun 2003 [EMAIL PROTECTED] wrote: > I was researching on cache replacement strategy as well. 2Q has one > disadvantage see this exellent paper: > http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper > "ARC: A Self-Tuning, Low Overhead Replacement Cache" for theory and "One > U

Re: [HACKERS] lru cache replacement

2003-06-24 Thread Yutaka tanida
On Wed, 25 Jun 2003 00:43:56 +0900 Yutaka tanida <[EMAIL PROTECTED]> wrote: > > BTW, when you were running your test case, what shared_buffers did you > > use? > > I use 16,64,256 and 4096. I missed. My shown result(+4% cache hit rate) is shared_buffers=64. --

Re: [HACKERS] lru cache replacement

2003-06-24 Thread Yutaka tanida
On Tue, 24 Jun 2003 10:27:09 -0400 Tom Lane <[EMAIL PROTECTED]> 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. How about cache hit

Re: [HACKERS] lru cache replacement

2003-06-24 Thread Tatsuo Ishii
> Yutaka tanida <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] 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 pre

Re: [HACKERS] lru cache replacement

2003-06-24 Thread Tom Lane
Yutaka tanida <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] 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 fr

Re: [HACKERS] lru cache replacement

2003-06-24 Thread Yutaka tanida
xoror, On Tue, 24 Jun 2003 12:13:51 +0200 (MEST) [EMAIL PROTECTED] wrote: > I was researching on cache replacement strategy as well. 2Q has one > disadvantage see this exellent paper: > http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper > "ARC: A Self-Tuning, Low Overhead Replacement