Re: win32 performance - fsync question

> >Doesn't Windows support O_SYNC (or even better O_DSYNC) flag to
open()?
> >That should be the Posixy spelling of FILE_FLAG_WRITE_THROUGH, if the
> >latter means what I suppose it does.
>
> They should, but someone said it didn't work. I haven't followed up on
> it, though, so it is quite possible it works. If so, it is definitly
> worth trying.

Yes, and the other issue is that FlushFileBuffers() does not play nice
with raid controllers, it actually overrides their write caching so that
you can not get around the fsync performance issue using raid + bbu on
most configurations.

> >> Not much to do about the bgwriter, the way it is designed it *has*
to
> >> fsync during checkpoint.
> >
> >Theoretically at least, the fsync during checkpoints should not be a
> >performance killer.

I agree: it's the WAL sync that is the problem. I don't mind a slower
sync during checkpoint because that is controllable. However, there is
also the raid issue.

> If you run a tight benchmark past a checkpoint, it will make an effect
> if the fsync takes twice as long as it does on unix. If the checkpoint
> happens when other I/O is fairly low then it shuold not have an
effect.
>
> Merlin, was that by any chance you? We've been talking about these
> things quite a lot :-)

> >So: try O_SYNC instead of fsync for WAL, ie, wal_sync_method =
> >open_sync or open_datasync.
>
> Definitly worth cehcking out.

Yeah.

Merlin