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 по дате отправления: