Re: lru cache replacement

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: lru cache replacement
Дата
Msg-id 20030624.235934.41643845.t-ishii@sra.co.jp
обсуждение исходный текст
Ответ на Re: lru cache replacement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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?

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: pg_get_triggerdef in pg_dump