| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, "Staale Smedseng" <Staale(dot)Smedseng(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why are we waiting? |
| Date: | 2008-02-07 23:23:07 |
| Message-ID: | 18142.1202426587@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> This is a tangent but are these actual Postgres processes? What's the logic
> behind trying to run a 1,000 processes on a box with 16 cpus?
We should certainly be careful about trying to eliminate contention in
this scenario at the cost of making things slower in more normal cases,
but it seems interesting to stress the system just to see what happens.
> Was this with your patch to raise the size of the clog lru?
That's an important question.
> What is MaxBackends actually set to for the runs.
That I think is not. I'm fairly sure there are no performance-relevant
paths in which cost is driven by MaxBackends rather than the actual
current number of live backends. Certainly nothing in or around the
ProcArray would act that way.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-02-07 23:25:07 | Re: configurability of OOM killer |
| Previous Message | Magnus Hagander | 2008-02-07 22:59:37 | Re: PostgreSQL 8.4 development plan |