Re: Log levels for checkpoint/bgwriter monitoring

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)

In response to

Browse pgsql-hackers by date

  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