Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> >> > If the background cleaner has to not just write() but write/fsync or
> >> >> > write/O_SYNC, it isn't going to be able to clean them fast enough. It
> >> >> > creates a bottleneck where we didn't have one before.
> >> >> >
> >> >> > We are trying to eliminate an I/O storm during checkpoint, but the
> >> >> > solutions seem to be making the non-checkpoint times slower.
> >> >> >
> >> >>
> >> >> It looks as if you're assuming that I am making the backends unable to
> >> >> write on their own, so that they have to wait on the checkpointer. I
> >> >> never said that.
> >> >
> >> > Maybe I missed it but are those backend now doing write or write/fsync?
> >> > If the former, that is fine. If the later, it does seem slower than it
> >> > used to be.
> >>
> >> In my all_performance.v4.diff they do write and the checkpointer does
> >> write+sync.
> >
> > Again, sorry to be confusing --- I might be good to try write/fsync from
> > the background writer if backends can do writes on their own too without
> > fsync. The additional fsync from the background writer should reduce
> > disk writing during sync(). (The fsync should happen with the buffer
> > unlocked.)
>
> No, you're not. But thank you for suggesting what I implemented.
OK, I did IM with Jan and I understand now --- he is using write/sync
for testing, but plans to allow several ways to force writes to disk
occasionally, probably defaulting to fsync on most platforms. Backend
will still use write only, and a checkpoint will continue using sync().
The qustion still open is whether we can push most/all writes into the
background writer so we can use fsync/open instead of sync. My point
has been that this might be hard to do with the same performance we have
now.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073