Re: Reasoning behind process instead of thread based

Martijn van Oosterhout wrote:
> A lot of these advantages are due to sharing an address space, right?
> Well, the processes in PostgreSQL share address space, just not *all*
> of it. They communicate via this shared memory.
> 
Whitch is a different beast altogether. The inter-process mutex handling 
that you need to synchronize shared memory access is much more expensive 
than the mechanisms used to synchronize threads.

>>2. All threads in a process can share a common set of optimized query plans.
> 
> 
> PostgreSQL could do this too, but I don't think anyone's looked into
> sharing query plans, probably quite difficult.
> 
Perhaps. It depends on the design. If the plans are immutable once 
generated, it should not be that difficult. But managing the mutable 
area where the plans are cached again calls for expensive inter-process 
synchronization.

> Table data is already shared. If two backends are manipulating the same
> table, they can lock directly via shared memory rather than some OS
> primitive.
> 
Sure, some functionality can be achieved using shared memory. But it 
consumes more resources and the mutexes are a lot slower.

> I think PostgreSQL has nicely combined the benefits of shared memory
> with the robustness of multiple processes...

So do I. I've learned to really like PostgreSQL and the way it's built, 
and as I said in my previous mail, I'm not advocating a switch. I just 
react to the unfair bashing of multi-threaded systems.

Regards,
Thomas Hallgren