Ответ: [HACKERS] Possible performance improvement: buffer replacement policy
От | Mikheev, Vadim |
---|---|
Тема | Ответ: [HACKERS] Possible performance improvement: buffer replacement policy |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A230327BB@SECTORBASE1 обсуждение исходный текст |
Ответы |
Re: Ответ: [HACKERS] Possible performance improvement: buffer replacement policy
|
Список | pgsql-hackers |
Excuse me but what is LRU-2? I know that in Oracle unused buffers are not in simple LRU list: Oracle tries to postpone writes as long as possible -:) Vadim > ----- Исходное сообщение ----- > От: Tom Lane [SMTP:tgl@sss.pgh.pa.us] > Отправлено: 16 ieoya?y 2000 a. 8:50 > Кому: Bruce Momjian > Копия: pgsql-hackers@postgreSQL.org > Тема: Re: [HACKERS] Possible performance improvement: buffer > replacement policy > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> It looks like it wouldn't take too much work to replace shared buffers > >> on the basis of LRU-2 instead of LRU, so I'm thinking about trying it. > >> > >> Has anyone looked into this area? Is there a better method to try? > > > Sounds like a perfect idea. Good luck. :-) > > Actually, the idea went down in flames :-(, but I neglected to report > back to pghackers about it. I did do some code to manage buffers as > LRU-2. I didn't have any good performance test cases to try it with, > but Richard Brosnahan was kind enough to re-run the TPC tests previously > published by Great Bridge with that code in place. Wasn't any faster, > in fact possibly a little slower, likely due to the extra CPU time spent > on buffer freelist management. It's possible that other scenarios might > show a better result, but right now I feel pretty discouraged about the > LRU-2 idea and am not pursuing it. > > regards, tom lane
В списке pgsql-hackers по дате отправления: