However, that Apache situation, multithreading *like* things together (request handling), is a more reasonable act than say, turning all of PostgreSQL into a monolithic process. PostgreSQL is a much more heterogeneous system than Apache, with potentially more interesting ways to lock up than Apache with its rather simple overall mission.

Sure it sounds interesting to try a branch of pg with, for example, just the sessions being multithreaded - but then how DOES one forcibly stomp on some session that has grabbed some critical lock without crashing other users' sessions? Killing off a session's thread inside of a MT'ed session handler without putting any other threads at risk would be the first problem (and an admin is likely to use "ps -Lef" to find the thread ID and then "kill"). Many MT programs I see lose their little minds if a thread is killed from outside.

Going too crazy with threads can also cause performance issues, since there is overhead - just less than for processes - around thread creation/switching/etc, and is why thread pools are common. There's a short article about this at:

    https://stackoverflow.com/questions/5961536/what-is-best-a-single-threaded-or-a-multi-threaded-server/5964238#5964238

There's some theory about how multithreading to handle a bunch of fds versus using poll / nonblocking I/O in a singlethreaded solution being equivalent at some level in computing science, but skill sets tend to matter more in practice.

This is a pretty good page on the options in general, though dated (anyone already know of a newer equivalent to it?):

    http://www.kegel.com/c10k.html

I feel sure work has been put into making kernel support for both MT *and* the poll and nonblocking I/O models more efficient since then. :-)