Re: lru cache replacement

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: yutaka(at)nonsensecorner(dot)com, xoror(at)infuse(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: lru cache replacement
Date: 2003-06-24 14:59:34
Message-ID: 20030624.235934.41643845.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

It's very easy to test sequencial scans using pgbench: just drop the
index from account table. I am using this technique to generate heavy
loads.
--
Tatsuo Ishii

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2003-06-24 15:02:56 Re: pg_get_triggerdef in pg_dump
Previous Message Tom Lane 2003-06-24 14:51:09 Re: Many Pl/PgSQL parameters -> AllocSetAlloc(128)?