Shachar Shemesh wrote:
> Greg Stark wrote:
>
> >That said, I'm curious why the emulated servers performed better than
the
> >Native Windows port. My first thought is that they probably aren't
> syncing
> >every write to disk so effectively they're defeating the fsyncs,
allowing
> the
> >host OS to buffer disk writes.
> >
> >
> I havn't tested it, and it's certanly possible. However, please bear
in
> mind that it is also possible that it just gives better performance.
>
> The reason this may be possible is that the emulation layer gets the
CPU
> (and other resources) from the OS in bulk, and decides on it's own how
> to allocate it to the various processes running within the emulation.
> Inparticular, this "on it's own" is done using the stock Linux kernel.
> As Postgresql works sufficiently better on Linux than on Windows, this
> yields better performance.
'better' does not mean 'faster'. Win32 has a pretty decent journaling
filesytem (ntfs) and a good I/O subsystem which includes IPC. Process
management is poor compared to newer linux kernels but this is
unimportant except in extreme cases. Right now the win32 native does
not sync() (but does fsync()). So, the performance is somewhere between
fsync = off and fsync = on (probably much closer to fsync = on). It is
reasonable to assume that the win32 port will outperform the unix
versions at many tasks (at the expense of safety) until the new sync()
code is put in.
If tested on the same source base, 40-60% differences can only be coming
from the I/O subsystem. There are other factors which aren't clear from
this exchange like what version of gcc, etc.
Merlin