Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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>
>Also, the cntxDirty mechanism allows a block to be dirtied without
>changing the ARC state at all.

... which might kill this proposal anyway.


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-12-30 00:57:15
Subject: Re: Shared row locking
Previous:From: Manfred KoizarDate: 2004-12-30 00:14:43
Subject: Re: Shared row locking

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group