On Wed, May 30, 2012 at 2:55 PM, Bruce Momjian <br...@momjian.us> wrote: > On Wed, May 30, 2012 at 11:51:23AM -0700, Jeff Janes wrote: >> On Wed, May 30, 2012 at 11:23 AM, Bruce Momjian <br...@momjian.us> wrote: >> > On Wed, May 30, 2012 at 11:06:45AM -0700, Jeff Janes wrote: >> >> On Wed, May 30, 2012 at 10:57 AM, Bruce Momjian <br...@momjian.us> wrote: >> >> > On Wed, May 30, 2012 at 10:38:10AM -0700, Jeff Janes wrote: >> >> >> >> >> >> Isn't that what the buffers_alloc from pg_stat_bgwriter is ? >> >> > >> >> > The issue is that once a buffer is removed from the free list, it is >> >> > never returned to the free list. >> >> >> >> A buffer doesn't need to be removed from the linked list in order for >> >> buffers_alloc to get incremented. >> > >> > Seems buffers_alloc is the number of calls to StrategyGetBuffer(), which >> > tells how many time we have requested a buffer. Not sure how that helps >> > measure buffer pressure. >> >> Once the linked list is empty, every request for a buffer to read a >> new page into must result in the eviction of the previous occupant >> from this conceptual freelist buffer (except perhaps for some race >> conditions). Isn't that what you wanted? Except that the >> buffers_alloc does not get incremented when the StrategyGetBuffer is >> satisfied by a ring strategy rather than the default strategy. > > Well, the ideal case is that I could find out how often data that is > near to be discarded is actually needed, hence the "reclaimed" field > that is often important for kernel memory presssure reporting on older > operating systems. I will post an email soon about my theory of why > buffer pressure is an important thing to report to users.
Ah, now I see. By reclaimed I thought you meant claimed for reuse with a new page, but you mean it was found to already have the page we wanted and a usagecount of zero and was unpinned, and so would have been in danger of eviction if we hadn't just now pinned it and bumped the usagecount. Yeah, I don't think anything currently reported will help with that. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers