BTW, I've been wondering lately if we'd not be better off to look at using threading in the Windows port, if it'd help us get around the fork/exec data transfer problem. I'm not sure that it would, mind you, but if it would give an answer it might be a lot less painful than solving the data transfer problem directly.
I am sure you are correct. The whole Windows API is more multi-thread friendly than multi-process friendly, and operates far more efficiently that way, as I understand it. There is also some potential benefit on some *nix systems, where thread creation is far less costly than forking, or at least this used to be the case last time I looked at it.
Not that I like Windows all that much, but using it for a server is becoming more defensible as an option. As for portability, what *nix is there these days that doesn't have some sort of lightweight thread support?
Our main objections to threading in the past have always been lack of portability and loss of robustness. Portability isn't an issue for a Windows-only solution, and I'm not too concerned about the other either, since I'll never think that Windows would be a place to run a production server anyway.
Maybe the relevant parts of the system need to be abstracted out and threading generally made a build time option (on by default for Windows, off by default otherwise, maybe?)
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
