On Tue, May 22, 2012 at 10:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Mind you, I think this whole area of the code needs some reengineering
>> for better performance, but I'm not sure this is the right place to
>> start. What I think is really bad is that we're forcing every
>> BufferAlloc() to iterate over buffers checking whether each one is
>> evictable.
>
> Well, keep in mind that that action is not merely there to obtain a
> victim buffer; it is also maintaining the global LRU state (by
> decrementing the usage counts of buffers it passes over). I don't think
> you can change it to simply look only at a predetermined freelist
> without seriously compromising the overall quality of our buffer
> replacement decisions.
The idea would be to have a background process (like bgwriter)
maintain the global LRU state and push candidate buffers onto the
freelist. Then foreground processes can just pop them off the list
and recheck that they haven't been pinned meanwhile. As long as we
don't let the background sweep get too far ahead of actual allocation
needs, I don't think this would change the quality of buffer
allocation much at all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company