3 ms·

Any recommended resources explaining the pitfalls of multiprocess vs multithreaded?

• the_duke 4y ago
  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.
• paulryanrogers 4y ago
  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.