Takayuki Tsunakawa wrote: > From: "Magnus Hagander" <[EMAIL PROTECTED]> >> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq