Re: Clock sweep not caching enough B-Tree leaf pages?

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Clock sweep not caching enough B-Tree leaf pages?
Дата
Msg-id CAM-w4HP5c+93R_g4edd8kvKZrQ60c=d+Wz56+p-L7D0SWdg+=A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Clock sweep not caching enough B-Tree leaf pages?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Clock sweep not caching enough B-Tree leaf pages?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<p dir="ltr">I've been meaning to write this since PGConf and now isn't a great time since I'm on my phone but I think
it'stime.<p dir="ltr">The way the clock sweep algorithm is meant to be thought about is that it's an approximate lru.
Eachusage count corresponds to an ntile of the lru. So we don't know which buffer is least recently used but it must be
inthe set of buffers with usage count 0 and that should be 1/nth of all the buffers.<p dir="ltr">In order for that
propertyto be maintained though the usage count for some buffer should be getting decremented every time we touch a
buffer.That is, every time we promote one buffer to the most recently moved ntile we should be demoting some other
buffer.<pdir="ltr">The way our cache works we promote when a buffer is accessed but we only demote when a buffer is
flushed.We flush a lot less often than we touch buffers so it's not surprising that the cache ends up full of buffers
thatare all in the "most recently used" section.<p dir="ltr">Now it's complicated by the fact that we aren't promoting
buffersdirectly to the most recently used ntile. We're incrementing the usage count by one. That makes it more of a
"leastfrequently used" list rather than a lru. I think that's a mistake but I recall some debate about that when it
firstwent in. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Clock sweep not caching enough B-Tree leaf pages?
Следующее
От: David Steele
Дата:
Сообщение: Re: Turning off HOT/Cleanup sometimes