Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: Forking vs. Threading


  • From: Neil Conway <neilc(at)samurai(dot)com>
  • To: Shridhar Daithankar <shridhar(at)frodo(dot)hserus(dot)net>
  • Cc: pgsql-advocacy(at)postgresql(dot)org, bryan(dot)encina(at)valleypres(dot)org
  • Subject: Re: Forking vs. Threading
  • Date: Fri, 19 Mar 2004 10:19:52 -0500
  • Message-id: <DE9C70CB-79B8-11D8-AFE3-000A95AB279E@samurai.com> <text/plain>

On 19-Mar-04, at 9:08 AM, Shridhar Daithankar wrote:
Bryan Encina wrote:
MySQL and Firebird use threads and Postgres forks.  Forking is ok,
unless you have many database connections.  The more connections the
more processes.  I noticed while profiling an application that every
connection alone was taking over 1MB of memory.  This based on the
process per connection gripe I have.

Umm.. Notcied how much of that 1MB is shared?

Also, I'd expect that the amount of memory that a busy installation should be devoting to caching I/O (whether done by the DBMS or the kernel) will dwarf the amount of memory each backend has allocated privately.

Assuming the kernel implements COW (which is reasonable, of course), I don't think the overall difference in memory footprint should be very significant -- or rather, if it is, it results from something other than the choice between threads and fork().

-Neil




Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group