Trevor Talbot wrote:
> On 11/28/07, Magnus Hagander <magnus@hagander.net> wrote:
>
>> On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
>>>> Yes, very much so. Windows lacks the fork() concept, which is what makes
>>>> PostgreSQL much slower there.
>>> So grossly slower process creation would kill postgres connection times. But
>>> what about the cases where persistent connections are used? Is it the case
>>> also that Windows has a performance bottleneck for interprocess
>>> communication?
>> There is at least one other bottleneck, probably more than one. Context
>> switching between processes is a lot more expensive than on Unix (given
>> that win32 is optimized towards context switching between threads). NTFS
>> isn't optimized for having 100+ processes reading and writing to the
>> same file. Probably others..
>
> I'd be interested to know what this info is based on. The only
> fundamental difference between a process and a thread context switch
> is VM mapping (extra TLB flush, possible pagetable mapping tweaks).
Generally, lots of references I've seen around the net and elsewhere. If
I'm not mistaken, the use of threads over processes was listed as one of
the main reasons why SQL Server got such good performance on Windows
compared to it's competitors. But I don't have my Inside SQL Server
around to check for an actual reference.
> And why would NTFS care about anything other than handles?
Not sure, again it's just something I've picked up from what others have
been saying. I should perhaps have been clearer that I don't have any
direct proof of that one.
> I mean, I can understand NT having bottlenecks in various areas
> compared to Unix, but this "threads are specially optimized" thing is
> seeming a bit overblown. Just how often do you see threads from a
> single process get contiguous access to the CPU?
On a CPU loaded SQL server, fairly often I'd say. But certainly not always.
//Magnus