Skip site navigation (1) Skip section navigation (2)

Re: Reasoning behind process instead of thread based

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-27 20:07:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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.

> 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.
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.

> Threaded servers have one main advantate:
> Threads are lightweight processes and starting a new thread is faster
> than starting a new executable.
A few more from the top of my head:
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.

Thomas Hallgren

In response to


pgsql-general by date

Next:From: Thomas HallgrenDate: 2004-10-27 20:10:05
Subject: Re: Bug or stupidity
Previous:From: Daniel SavardDate: 2004-10-27 19:44:57
Subject: Re: Array values and foreign keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group