| 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: | 2004-03-19 15:19:52 |
| Message-ID: | DE9C70CB-79B8-11D8-AFE3-000A95AB279E@samurai.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-advocacy |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2004-03-19 18:52:54 | Re: another postgres article |
| Previous Message | Robert Bernier | 2004-03-19 14:21:54 | another postgres article |