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

Re: RC2 and open issues

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RC2 and open issues
Date: 2004-12-21 04:50:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> Exactly.  But 1% would be uselessly small with this definition.  Offhand
> >> I'd think something like 50% might be a starting point; maybe even more.
> >> What that says is that a page isn't a candidate to be written out by the
> >> bgwriter until it's fallen halfway down the LRU list.
> > So we are not scanning by buffer address but using the LRU list?  Are we
> > sure they are mostly dirty?
> No.  The entire point is to keep the LRU end of the list mostly clean.
> Now that you mention it, it might be interesting to try the approach of
> doing a clock scan on the buffer array and ignoring the ARC lists
> entirely.  That would be a fundamentally different way of envisioning
> what the bgwriter is supposed to do, though.  I think the main reason
> Jan didn't try that was he wanted to be sure the LRU page was usually
> clean so that backends would seldom end up doing writes for themselves
> when they needed to get a free buffer.
> Maybe we need a hybrid approach: clean a few percent of the LRU end of
> the ARC list in order to keep backends from blocking on writes, plus run
> a clock scan to keep checkpoints from having to do much.  But that's way
> beyond what we have time for in the 8.0 cycle.

OK, so we scan from the end of the LRU.  If we scan X% and find _no_
dirty buffers perhaps we should start where we left off last time.

If we don't start where we left off, I am thinking if you do a lot of
writes then do nothing, the next checkpoint would be huge because a lot
of the LRU will be dirty because the bgwriter never got to it.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: lsunleyDate: 2004-12-21 05:05:46
Subject: Re: rc2 bundled
Previous:From: Tom LaneDate: 2004-12-21 04:20:46
Subject: Re: RC2 and open issues

pgsql-patches by date

Next:From: Gavin SherryDate: 2004-12-21 05:11:46
Subject: Re: RC2 and open issues
Previous:From: Tom LaneDate: 2004-12-21 04:20:46
Subject: Re: RC2 and open issues

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