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