Re: Bgwriter behavior - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Bgwriter behavior
Date
Msg-id jsr5t0lem4du7lsoki13bt7iu3uljs1bi6@4ax.com
Whole thread Raw
In response to Re: Bgwriter behavior  ("Jim C. Nasby" <decibel@decibel.org>)
List pgsql-hackers
[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@decibel.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@sss.pgh.pa.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.

ServusManfred



pgsql-hackers by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: Shared row locking
Next
From: Tom Lane
Date:
Subject: Re: Shared row locking