Robert Berry <berrydigi...@gmail.com> writes: > I'm looking at doing a calculation to determine the number of free buffers > available. A n example ratio that is based on some data structures in > freelist.c as follows:
> (StrategyControl->lastFreeBuffer - StrategyControl->firstFreeBuffer) / > (double) NBuffers > Is there a way to get access to the StrategyControl pointer in the context > of a background worker? The BufferStrategyControl struct is in shared memory, so you can certainly get at it. One way would be to modify freelist.c to export its static pointer variable. Alternatively, you could call ShmemInitStruct an extra time to look up the struct for yourself, and then save it in your own static variable. Having said that, though, I'm pretty dubious of the premise. I trust you realize that the above calculation is entirely wrong; firstFreeBuffer and lastFreeBuffer are list head and tail pointers, and have no numerical relation to the list length. The only way to determine the list length accurately would be to chase down the whole list, which you'd have to hold the BufFreelistLock while doing, which'd be disastrous for performance if the list was long. (If you're okay with modifying the backend code you could dodge this by teaching freelist.c to maintain a counter, I guess.) An even bigger issue is that it's not clear that the length of the free list is actually a useful number to have; in steady-state usage it frequently is always zero. Buffers only get put back on the freelist if they're invalidated, eg by dropping the relation they belonged to. Normal usage tends to allocate buffers by reclaiming ones whose usage_count has reached zero in the clock sweep algorithm. So a better picture of the availability of buffers would require scanning the buffer pool to see how many there are of each usage_count level. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers