Re: PostgreSQL
[email protected] Thu, 2 Feb 2006 01:19:06 +0000
| Newsgroups | gmane.os.netbsd.devel.performance |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2 Feb 2006 11:04:33 +1000 George Michaelson <[email protected]> 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.