Subject: Re: PostgreSQL
To: George Michaelson <ggm@apnic.net>
From: None <segv@netctl.net>
List: tech-perform
Date: 02/02/2006 01:19:06
On Thu, 2 Feb 2006 11:04:33 +1000
George Michaelson <ggm@apnic.net> wrote:

> 
> I didn't think the wins for threads over processes was that clear cut
> actually. 
> 
> Is it *really* just a done deal now that its cheaper to do lightweight
> context switching inside a process, than to have more processes? 
> 
> Always?
> 
> For all Applications?
> 
> -george

Threads can be created MUCH faster, they take up a lot less memory and they run
in the same address space, which means access to shared data is easy and fast.
If PostgreSQL forks a new process for a each connection to a database, it will
be 1) slow, 2) it'll use up all the memory much sooner.

So, fine grained threading is the way forward, especially on newer multicore
CPUs. But even threads have limitations, for example a threaded web server will
not be as efficient as the one that uses a small number of threads + kernel
event notification (e.g. kqueue, /dev/poll, epoll, etc). Each application will
have different requirements and constraints and you'd have to use the most
efficient framework provided by the host operating system.