Subject: Re: PostgreSQL
To: Alfred Perlstein <bright@mu.org>
From: Patrick Welche <prlw1@newn.cam.ac.uk>
List: tech-net
Date: 02/02/2006 15:37:29
On Wed, Feb 01, 2006 at 06:58:04PM -0800, Alfred Perlstein wrote:
> * Neil Conway <neilc@samurai.com> [060201 18:49] wrote:
> > On Thu, 2006-02-02 at 00:49 +0000, segv@netctl.net wrote:
> > > 1. I was reading somewhere that PostgreSQL was not multithreaded. This can have
> > > a significant impact if you have a busy database server. Multicore CPUs
> > > designed for executing 10s and 100s of threads simultaneously are just around
> > > the corner (Sun's T1 processors). So fine grained threaded applications are the
> > > future.
> > 
> > Whether threads or processes are used to implement concurrency does not
> > really affect how fine-grained the concurrency is. That is, I don't see
> > how using multiple processes and fork() makes an application inherently
> > less suitable to multicore servers than an application using threads.
> 
> Ok, I'm on the fence about threads, but the reason why they are a
> gain over processes, on multi-core in particular is that the shared
> address space means that if you switch between two threads you do
> not have to invalidate tlbs or caches during the context switch.
> 
> Also, thread to thread synchronization is somewhat faster than process
> to process synchronization.  Honestly, the default thread synchronization
> primitives typically blow the inter-process ones out of the water,
> although there are some OS's and libraries that provide relatively
> fast/cheap inter process syntonization.
> 
> Also, I'm pretty sure that synchronization between threads doesn't
> require locked bus cycles, only atomic ops, again another saving.
> 
> But threads aren't always the best thing out there, the code gets
> a lot more complicated and crash prone and you wind up sometimes
> getting screwed because third party code isn't thread safe...

Isn't your last paragraph the reason PostgreSQL sticks to processes?
Companies A and B each have databases running from your server.
Company A has written flaky procedures which segfault its backends.
(some processes disappear) Company B doesn't care - its backends
don't share any memory with them, all is well.

Cheers,

Patrick