On Thu, 2009-02-05 at 13:18 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-05 at 11:46 +0200, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >
> >>> So we might end up flushing more often *and* we will be doing it
> >>> potentially in the code path of other users.
> >> For example, imagine a database that fits completely in shared buffers.
> >> If we update at every XLogFileRead, we have to fsync every 16MB of WAL.
> >> If we update in XLogFlush the way I described, you only need to update
> >> when we flush a page from the buffer cache, which will only happen at
> >> restartpoints. That's far less updates.
> >
> > Oh, did you change the bgwriter so it doesn't do normal page cleaning?
>
> No. Ok, that wasn't completely accurate. The page cleaning by bgwriter
> will perform XLogFlushes, but that should be pretty insignificant. When
> there's little page replacement going on, bgwriter will do a small
> trickle of page cleaning, which won't matter much.
Yes, that case is good, but it wasn't the use case we're trying to speed
up by having the bgwriter active during recovery. We're worried about
I/O bound recoveries.
> If there's more page
> replacement going on, bgwriter is cleaning up pages that will soon be
> replaced, so it's just offsetting work from other backends (or the
> startup process in this case).
Which only needs to be done if we follow this route, so is not an
argument in favour.
Using more I/O in I/O bound cases makes the worst case even worse.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support