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.
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:
1. PostgreSQL tries to read data from disk into database cache.
2. The kernel tries to allocate filesystem buffers by paging out
PostgreSQL's memory (possibly shared buffers).
3. PostgreSQL finds data requested by its clients in database cache,
and tries to get it in memory.
4. But the shared buffers are paged out, and page-ins happen.
> 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.
> 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.
