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 16:23:14
Message-ID: CA+TgmoZuCwDVOtqqChKFD801n-D8yWKRPAZZz8h0Qv1iBx_zgw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 22, 2012 at 12:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> With respect to the control logic for the background writer, one idea
>> I had was to get rid of the idea that the background writer's job is
>> to write in advance of the strategy point.  Instead, every time the
>> clock sweep passes over a dirty buffer that is otherwise evictable, we
>> add it to a queue of things that the bgwriter should clean.  Those
>> buffers, once cleaned, go on the free list.  Maybe some variant of
>> that could work with your idea.
>
> Both ends of that imply centralized data structures that could become
> contention bottlenecks, so it doesn't sound tremendously appealing to
> me.  Maybe it can work as long as nobody has to lock the lists for long,
> but I'd rather think of approaches with no central point of contention.

If we're going to throw our current algorithm over wholesale, I'd
rather use some approach that has been demonstrated to work well in
other systems. Buffer eviction is a problem that's been around since
the 1970s, and our algorithm is just about that old. I realize that
there are (legitimate) concerns about what might be patented, but
hopefully that doesn't mean we're not allowed to consult the
literature in any way. If that were the case, we wouldn't have SSI.

--
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 Florian Pflug 2012-05-22 16:23:56 Re: Per-Database Roles
Previous Message Tom Lane 2012-05-22 16:18:44 Re: Per-Database Roles