Quoting bits and pieces from the PostgreSQL site... Please note that I've absolutely no idea of the merits of these arguments -- they merely didn't fit in a comment.

From the Developer FAQ ("Why threads aren't used..."):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

Threads are not currently used instead of multiple processes for backends because: (...)

• An error in one backend can corrupt other backends if they're threads within a single process
• Speed improvements using threads are small compared to the remaining backend startup time.
• Sharing of read-only executable mappings and the use of shared_buffers means processes, like threads, are very memory efficient
• Regular creation and destruction of processes helps protect against memory fragmentation, which can be hard to manage in long-running processes

From the Todo list ("Features we do not want"):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

All backends running as threads in a single process (not wanted)

 

This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. (...)

So, again... I've absolutely no idea of the merits of the above. It was merely too long to fit in a comment.

Quoting bits and pieces from the PostgreSQL site... Please note that I've absolutely no idea of the merits of these arguments -- they merely didn't fit in a comment.

From the Developer FAQ ("Why threads aren't used..."):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

Threads are not currently used instead of multiple processes for backends because: (...)

• An error in one backend can corrupt other backends if they're threads within a single process
• Speed improvements using threads are small compared to the remaining backend startup time.
• Sharing of read-only executable mappings and the use of shared_buffers means processes, like threads, are very memory efficient
• Regular creation and destruction of processes helps protect against memory fragmentation, which can be hard to manage in long-running processes

From the Todo list ("Features we do not want"):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

All backends running as threads in a single process (not wanted)

This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. (...)

So, again... I've absolutely no idea of the merits of the above. It was merely too long to fit in a comment.