Oracle is 25 million lines of code vs 1.3 million lines of code of PostgreSQL Still Oracle don't have all basic isolation levels. Only the Read-Commited works perfect. And DDL operations are still not transactional. We should think which is inefficient design. The process model may not be very "efficient" as thread model. but it is more "stable" and more "secure". Benchmark results are not bad either.

Oracle, in the past, was also a multi-process model on Linux. It looks like the multi-threaded model was an optional change at some point around Oracle 12.

To get around the inefficiencies of spawning many processes, I put pgbouncer in front of PostgreSQL.

> The process model is known to be pretty horrible.

isn't this still processes, just with shared memory?

Any recommended resources explaining the pitfalls of multiprocess vs multithreaded?

Postgres forks off a new process for each connection.

This introduces lot's of overhead across the board.

* Cross process communication is a lot more expensive (done via shared memory or as here via the file system)

* Switching between processes is a lot more expensive because each process has its own memory space, hence a switch flushes the TLB. Also more bookkeeping for the OS.

This is especially bad for a DB, which will usually spend most of its time waiting for IO, so can switch execution context all the time.

* Each process also has a distinct set of file descriptors, so those need to be cloned as well

* A dB needs lots of locks. Cross process locks are more expensive.

* ...

These things add up.

Biggest one I'm aware of is connections aren't threaded. And Pg tries to preallocate resources at the time of the connection. Together these make connections expensive compared to Mysql's threaded connections. Many folks run a connection pooler in front of Pg for this reason.

One pro of non-threaded is simplicity and no need for thread safety everywhere.