Re: Changing the default wal_sync_method to open_sync for Win32?

> >> I'd like to see this one also considered for 8.0.x, though I'd
> >> certainly like to see some more testing as well. Perhaps it's
> >> suitable for the "8.0.x with extended testing" that is planned for
> >> the ARC replacement code?
> >>
> >> It does make a huge difference on win32. While we definitly don't
> >> want to risk data, a 60% speedup in write intensive apps
> is a *lot*.
> >
> > Notice we never default to open_sync. However, on Win32,
> Magnus got a
> > 60% speedup by using open_sync, implemented using
> > FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I
> > think we should default to open_sync on Win32. The attached patch
> > implements this.
>
> Considering how stable an Operating System Windows *isn't*, I

The difference has nothing to do with the stability of the OS. It has to
do with wether we ignore the *hardware* write cache or not. Both methods
ignore the OS write cache.

> think the first thing Magnus states very much goes against
> making this the default:
> "While we definitely don't want to risk data..." ...
>
> Setting something like this that increases the risk to data
> should never be 'the default behaviour', but a conscious
> decision on the part of the administrator of the individual
> system ... and even then, with a good skull-n-cross bones
> warning around it so that they understand the risks ...

The same level of "risk due to write cache" exists on all other
operating systems already. (Actually, I only know it exists on linux,
but it sure looks like it exists on most others looking at performance
figures)

//Magnus