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.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.
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.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.
Sure, some functionality can be achieved using shared memory. But it consumes more resources and the mutexes are a lot slower.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.
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster