Re: Readme of Buffer Management seems to have wrong sentence

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Readme of Buffer Management seems to have wrong sentence
Date: 2012-05-22 14:08:47
Message-ID: CA+TgmoaM3K28u+EELSYFDixt=Wz67cg73rJDGAJVC8bjG+f-OA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 22, 2012 at 10:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-22 14:09:23 Re: Per-Database Roles
Previous Message Robert Haas 2012-05-22 14:04:25 Re: incorrect handling of the timeout in pg_receivexlog