Обсуждение: Ответ: [HACKERS] Possible performance improvement: buffer replacement policy

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

"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> Excuse me but what is LRU-2?

Like LRU, but using time to second most recent reference, instead of
most recent reference, to sort the buffers for recycling.  This gives
a more robust statistic about how often the page is actually being
touched.  (Or that's the theory anyway.)

> I know that in Oracle unused buffers are not in
> simple LRU list: Oracle tries to postpone writes
> as long as possible -:)

Manage dirty buffers separately from clean ones, you mean?  Hm, we could
do that.  With WAL it might even make sense, though before we tended to
flush dirty buffers so fast it would hardly matter.

            regards, tom lane