CreateProcess vs. CreateThread (was: Committing Resources to Win32)

Joshua D. Drake wrote:
> >problem is the ipc-daemon which has a tendency to crash. It seems
> >slower on writes, but that is strictly anecdotal. With synching off,
it
> >hums along happily.
> >
> It is slower on rights, connection startup, limited on connections,
> tcp/ip transfer and you should
> never run PostgreSQL with sync off unless you are not worried about
data
> integrity.

I agree 100%. See notes below.

> >The perceived win32 process management problems are a total red
herring.
> >
> >
> I disagree... read the other posts. CreateProcess does not scale like
> CreateThread.

Here is a good resource comparing process creation on Linux and NT (with
source).

http://www-106.ibm.com/developerworks/linux/library/l-rt7/?t=gr,Redhat=T
headsMgt

NT can create 150 processes/sec (vs. 300+ on Linux 2.4.2). Even with
the slower process creation time, most postgres applications will spend
a tiny fraction of their time inside process creation. Again, this is
much more relevant to a web server than a database server. Compile and
run the code supplied in the link if you don't believe me (and I don't
expect you to :)).

My point about cygwin was to try and illustrate that the performance
problems wrt postgres on win32 are almost certainly going to be I/O
based, not process based (as evidenced by the decent performance with
fsync=off), and this is due to the way files are synched (somebody
correct me if I'm wrong on this point). I would hate to see you spend a
bunch of time implementing threading only to find out you are better off
than with the cygwin version. In case I am wrong, it might be
informative to fire up a threaded port to see if the end justifies the
means. The best apples to apples comparison is to run cygwin/peerdirect
fsync=off vs. linux fsync=off. This is not useful in a production
sense, but will help tell the relative performance wrt threads vs.
processes.

My gut tells me the proper path is to:
1. Implement no frills process based port to win32 based on (as much as
possible) native sources and native build environment.
2. Troubleshoot specific performance problems, which will most likely be
on the I/O side. Fixing them may ultimately lead to api level file
calls (possibly including asynch I/O) on win32, which may be the only
way that platform will ever run postgres as good as on the unix side of
things.

Regards,
Merlin