From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: WIP: 2nd-generation buffer ring patch |
Date: | 2007-05-30 04:02:11 |
Message-ID: | 26720.1180497731@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> Based on my observations of buffer cache statistics, the number of pinned
> buffers at any time is small enough that in a reasonably sized buffer
> cache, I wouldn't expect a change in the pinned usage_count behavior to
> have any serious impact.
Fair enough. The patch I put up earlier tonight bumps usage_count at
PinBuffer instead of UnpinBuffer time, and leaves the clock sweep
behavior unchanged, which means that a buffer that had stayed pinned for
more than a clock-sweep cycle time could get recycled almost instantly
after being unpinned. That seems intuitively bad. If we make the clock
sweep code not decrement usage_count of a pinned buffer then the problem
goes away. I had expressed some discomfort with that idea, but I've got
to admit that it's only a vague worry not anything concrete. Barring
objections I'll adjust the patch to include the clock-sweep change.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-05-30 04:09:29 | Re: Logging checkpoints and other slowdown causes |
Previous Message | Greg Smith | 2007-05-30 03:35:23 | Re: WIP: 2nd-generation buffer ring patch |