Re: Design notes for BufMgrLock rewrite
От | Bruce Momjian |
---|---|
Тема | Re: Design notes for BufMgrLock rewrite |
Дата | |
Msg-id | 200502210419.j1L4J0613918@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Design notes for BufMgrLock rewrite (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > "Jim C. Nasby" <decibel@decibel.org> writes: > > The advantage of using a counter instead of a simple active > > bit is that buffers that are (or have been) used heavily will be able to > > go through several sweeps of the clock before being freed. Infrequently > > used buffers (such as those from a vacuum or seq. scan), would get > > marked as inactive the first time they were hit by the clock hand. > > Hmm. It would certainly be nearly as easy to adjust a counter as to > manipulate the RECENTLY_USED flag bit that's in the patch now. (You > could imagine the RECENTLY_USED flag bit as a counter with max value 1.) > > What I'm envisioning is that pinning (actually unpinning) a buffer > increments the counter (up to some limit), and the clock sweep > decrements it (down to zero), and only buffers with count zero are taken > by the sweep for recycling. That could work well, but I think the limit > needs to be relatively small, else we could have the clock sweep having > to go around many times before it finally frees a buffer. Any thoughts > about that? Anyone seen any papers about this sort of algorithm? One idea would be for the clock to check X% of the buffer cache and just recycle the page it saw with the lowest usage count. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: