Re: Bgwriter behavior

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bgwriter behavior
Date: 2004-12-30 00:15:45
Message-ID: jsr5t0lem4du7lsoki13bt7iu3uljs1bi6@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

[I know I'm late and this has already been discussed by Richrad, Tom,
et al., but ...]

On Tue, 21 Dec 2004 16:17:17 -0600, "Jim C. Nasby"
<decibel(at)decibel(dot)org> wrote:
>look at where the last page you wrote out has ended up in the LRU list
>since you last ran, and start scanning from there (by definition
>everything after that page would have to be clean).

This is a bit oversimplified, because that page will be moved to the
start of the list when it is accessed the next time.

A = B = C = D = E = F = G = H = I = J = K = L = m = n = o = p = q
^
would become

M = A = B = C = D = E = F = G = H = I = J = K = L = n = o = p = q
^

(a-z ... known to be clean, A-Z ... possibly dirty)

But with a bit of cooperation from the backends this could be made to
work. Whenever a backend takes the page which is the start of the
clean tail out of the list (most probably to insert it into another
list or to re-insert it at the start of the same list) the clean tail
pointer is advanced to the next list element, if any. So we would get

M = A = B = C = D = E = F = G = H = I = J = K = L = n = o = p = q
^

As a little improvement the clean tail could be prevented from
shrinking unnecessarily fast by moving the pointer to the previous
list element if this is found to be clean:

M = A = B = C = D = E = F = G = H = I = J = K = l = n = o = p = q
^

Maybe this approach could serve both goals, (1) keeping a number of
clean pages at the LRU end of the list and (2) writing out other dirty
pages if there's not much to do near the end of the list.

But ...
On Tue, 21 Dec 2004 10:26:48 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>Also, the cntxDirty mechanism allows a block to be dirtied without
>changing the ARC state at all.

... which might kill this proposal anyway.

Servus
Manfred

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-12-30 00:57:15 Re: Shared row locking
Previous Message Manfred Koizar 2004-12-30 00:14:43 Re: Shared row locking

Browse pgsql-patches by date

  From Date Subject
Next Message Hans-Jürgen Schönig 2004-12-30 12:44:36 Implementing RESET CONNECTION ...
Previous Message Tom Lane 2004-12-29 23:48:47 Re: patch for sun workshop compilation bug