| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: bg worker: general purpose requirements |
| Date: | 2010-09-18 03:43:15 |
| Message-ID: | 3701.1284781395@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Wow, 100 processes??! Really? I guess I don't actually know how large
> modern proctables are, but on my MacOS X machine, for example, there
> are only 75 processes showing up right now in "ps auxww". My Fedora
> 12 machine has 97. That's including a PostgreSQL instance in the
> first case and an Apache instance in the second case. So 100 workers
> seems like a ton to me.
The part of that that would worry me is open files. PG backends don't
have any compunction about holding open hundreds of files. Apiece.
You can dial that down but it'll cost you performance-wise. Last
I checked, most Unix kernels still had limited-size FD arrays.
And as you say, ProcArray manipulations aren't going to be terribly
happy about large numbers of idle backends, either.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tomas | 2010-09-18 05:41:53 | Re: bg worker: general purpose requirements |
| Previous Message | Robert Haas | 2010-09-18 03:21:13 | Re: bg worker: general purpose requirements |