| 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: | Whole Thread | Raw Message | 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 |