A long time ago, in a galaxy far far away, ‘threads’ were a programming novelty rarely used and seldom trusted. In that environment, the first PostgreSQL developers decided forking a process for each connection to the database is the safest choice. It would be a shame if your database crashed, after all.
Since then, a lot of water has flown under that bridge, but the PostgreSQL community has stuck by their original decision. It is difficult to fault their argument - as it's absolutely true that:
Each client having its own process prevents a poorly behaving client from crashing the entire database.
On modern Linux systems, the difference in overhead between forking a process and creating a thread is much lesser than it used to be.
Moving to a multithreaded architecture will require extensive rewrites.
However, in modern web applications, clients tend to open a lot of connections. Developers are often strongly discouraged from holding a database connection while other operations take place. “Open a connection as late as possible, close a connection as soon as possible”. But that causes a problem with PostgreSQL’s architecture - forking a process becomes expensive when transactions are very short, as the common wisdom dictates they should be. In ...
Read More on Datafloq
No comments:
Post a Comment