On 11/28/07, Magnus Hagander <magnus@xxxxxxxxxxxx> 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). And why would NTFS care about anything other than handles? 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? ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
