Re: Design notes for BufMgrLock rewrite
От | Tom Lane |
---|---|
Тема | Re: Design notes for BufMgrLock rewrite |
Дата | |
Msg-id | 18377.1108339007@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Design notes for BufMgrLock rewrite (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Design notes for BufMgrLock rewrite
Re: Design notes for BufMgrLock rewrite |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Tom Lane wrote: >> One thing I realized quickly is that there is no natural way in a clock >> algorithm to discourage VACUUM from blowing out the cache. I came up >> with a slightly ugly idea that's described below. Can anyone do better? > Uh, is the clock algorithm also sequential-scan proof? Is that > something that needs to be done too? If you can think of a way. I don't see any way to make the algorithm itself scan-proof, but if we modified the bufmgr API to tell ReadBuffer (or better ReleaseBuffer) that a request came from a seqscan, we could do the same thing as for VACUUM. Whether that's good enough isn't clear --- for one thing it would kick up the contention for the BufFreelistLock, and for another it might mean *too* short a lifetime for blocks fetched by seqscan. regards, tom lane
В списке pgsql-hackers по дате отправления: