Re: Log levels for checkpoint/bgwriter monitoring
От | Jim Nasby |
---|---|
Тема | Re: Log levels for checkpoint/bgwriter monitoring |
Дата | |
Msg-id | FA60F165-253F-4791-AF6B-7BEA34AF3D2B@decibel.org обсуждение исходный текст |
Ответ на | Re: Log levels for checkpoint/bgwriter monitoring (Greg Smith <gsmith@gregsmith.com>) |
Список | pgsql-hackers |
On Mar 9, 2007, at 7:57 AM, Greg Smith wrote: > On Fri, 9 Mar 2007, ITAGAKI Takahiro wrote: > >> "Pinned" means bufHdr->refcount > 0 and you don't distinguish >> pinned or recently-used (bufHdr->usage_count > 0) buffers in your >> patch. > > Thank you, I will revise the terminology used accordingly. I was > using "pinned" as a shortcut for "will be ignored by skip_pinned" > which was sloppy of me. As I said, I was trying to show how the > buffer cache looks from the perspective of the background writer, > and therefore lumping them together because that's how > SyncOneBuffer views them. A buffer cache full of either type will > be largely ignored by the LRU writer, and that's what I've been > finding when running insert/update heavy workloads like pgbench. > > If I might suggest a terminology change to avoid this confusion in > the future, I'd like to rename the SyncOneBuffer "skip_pinned" > parameter to something like "skip_active", which is closer to the > real behavior. I know Oracle refers to these as "hot" and "cold" > LRU entries. Well, AIUI, whether the buffer is actually pinned or not is almost inconsequential (other than if a buffer *is* pinned then it's usage count is about to become > 0, so there's no reason to consider writing it). What that parameter really does is control whether you're going to follow the LRU semantics or not... -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-hackers по дате отправления: