I have been watching this thread vs non-threaded discussion and am completely with the
process-only crew for a couple reasons, but lets look at a few things:
The process vs threads benchmark which showed 160us vs 120us, only did the process
creation, not the delayed hit of the "copy on write" pages in the new process. Just forking
is not as simple as forking, once the forked process starts to work, memory that is not
explicitly shared is copied to the new process once it is modified. So this is a hit,
possibly a big hit. Threads are far more efficient, it really is hard to debate.
I can see a number of reasons why a multithreaded version of a database would be good.
Asynchronous I/O perhaps, or even parallel joins, but with that being said, I think
stability and work are by far the governing factors. Introducing multiple threads into a
non-multithreaded code base invariably breaks everything.
So, we want to weight the possible performance gains of multithreads vs all the work and
effort to make them work reliably. The question is fundamentally, where are we spending our
time? If we are spending our time in context switches, then multithreading may be a way of
reducing this, however, in all the applications I have built with postgres, it is always
(like most databases) I/O bound or bound by computation.
I think the benefits of rewriting code to be multithreaded are seldom worth the work and
the risks, unless there is a clear advantage to do so. I think most would agree that any
increase in performance gained by going multithreaded would be minimal, and the amount of
work to do so would be great.