I'm not advocating a multi-threaded PostgreSQL server (been there, done that :-). But I still must come to the defense of multi-threaded systems in general.
You try to convince us that a single threaded system is better because it is more tolerant to buggy code. That argument is valid and I agree, a multi-threaded environment is more demanding in terms of developer skills and code quality.
But what if I don't write crappy code or if I am prepared to take the consequences of my bugs, what then? Maybe I really know what I'm doing and really want to get the absolute best performance out of my server.
There are clear advantages to separate process space for servers. 1. Separate threads can stomp on each other's memory space. (e.g. imagine a wild, home-brew C function gone bad).
Not all servers allow home-brewed C functions. And even when they do, not all home-brewers will write crappy code. This is only a clear advantage when buggy code is executed.
2. Separate processes can have separate user ids, and [hence] different rights for file access. A threaded server will have to either be started at the level of the highest user who will attach or will have to impersonate the users in threads. Impersonation is very difficult to make portable.
Yes, this is true and a valid advantage if you ever want access external and private files. Such access is normally discouraged though, since you are outside of the boundaries of your transaction.
Sure, but a memory leak is a serious bug and most leaks will have a negative impact on single threaded systems as well. I'm sure you will find memory leak examples that are fatal only in a multi-threaded 24x7 environment but they are probably very few overall.3. Separate processes die when they finish, releasing all resources to the operating system. Imagine a threaded server with a teeny-tiny memory leak, that stays up 24x7. Eventually, you will start using disk for ram, or even use all available disk and simply crash.
A few more from the top of my head:Threaded servers have one main advantate: Threads are lightweight processes and starting a new thread is faster than starting a new executable.
1. Threads communicate much faster than processes (applies to locking and parallel query processing).
2. All threads in a process can share a common set of optimized query plans.
3. All threads can share lots of data cached in memory (static but frequently accessed tables etc.).
4. In environments built using garbage collection, all threads can share the same heap of garbage collected data.
5. A multi-threaded system can apply in-memory heuristics for self adjusting heaps and other optimizations.
6. And lastly, my favorite; a multi-threaded system can be easily integrated with, and make full use of, a multi-threaded virtual execution environment such as a Java VM.
...
Regards, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
