From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Log levels for checkpoint/bgwriter monitoring |
Date: | 2007-03-09 21:38:10 |
Message-ID: | FA60F165-253F-4791-AF6B-7BEA34AF3D2B@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-09 21:40:46 | Re: Bug in VACUUM FULL ? |
Previous Message | Jim Nasby | 2007-03-09 21:34:49 | Re: Log levels for checkpoint/bgwriter monitoring |