Takayuki Tsunakawa wrote:
> From: "Magnus Hagander" <magnus@hagander.net>
>> Right. Which is why you're likely to see better performance if you
> keep
>> shared buffers smaller. There is something in dealing with it that's
>> slow on win32, per reports from the field. It needs to be
> investigated
>> further...
>> We've had reports that it's slow with large shared_buffers, yes.
>
> That's a shocking news. I'm sad.
It shouldn't make you sad until it has been proven that it's actually a
problem. And if we can do something about it :-)
> I wonder whether the field you are talking about set Windows to use
> more memory for programs than for filesystem cache, which is
> selectable from [System] applet of Control Panel (Oh, I wonder how my
> machine is set in this respect... have to check.) If filesystem cache
> is preferred, the following senario may be possible:
Could be, I haven't run the tests myself, and it was tests on production
systems, and not actual benchmark runs.
>> Are you sure you're not running this on for example
>> IDE disks with write-cache that lies? Windows will write through
> that
>> write-cache even if the disk lies, whereas most linux versions
> won't. At
>> least that used to be the case not too long ago, but there has also
> been
>> talking about fixign that in linux, so maybe that's done...
>
> I'm using a PC server whose disks are all SCSI. It has no IDE disk.
There goes that idea :-) Then you need to dig further into why it's such
a big difference.
>> Also note that when you run pg_bench on the local machine, you take
> a
>> much higher hit from the fact that context switching between
> processes
>> is a lot more expensive on Windows than it is on Linux. But it
> shouldn't
>> be big enough to explain the huge difference you had in your test.
>
> Yes, I suspect it, too. So, Oracle uses one multi-threaded server
> process on Windows, while it employs multi-process architecture. SQL
> Server is of course multi-threaded. SRA's original PostgreSQL for
> Windows (based on 7.x) was also multi-threaded.
Right. The windows MM and scheduler system is definitely geared for
multithreaded. But that would make pg on win32 too different from pg on
unix to be maintained without a significantly larger effort than today,
so unless you can find some non-intrusive way to sneak it in (which I
doubt), that's just not going to happen.
That said, the context switching overhead shouldn't be *that* large. but
it'd be interesting to see what the performance difference would be for
the same machine with pg_bench running on a different machine across a
fast network connection.
(BTW, another difference is that pg_bench on unix would be using unix
domain sockets and on windows it would be using tcp/ip. But that really
shouldn't make such a huge difference either, but I guess it would add a
bit to the factor)
//Magnus
