On Tue, May 22, 2012 at 10:01 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
