From: | Andreas Kostyrka <andreas(at)kostyrka(dot)org> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | creimer(at)brturbo(dot)com(dot)br, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Context switch storm |
Date: | 2006-11-03 16:16:31 |
Message-ID: | 1162570591.16439.21.camel@andi-lap |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Am Freitag, den 03.11.2006, 14:38 +0000 schrieb Richard Huxton:
> creimer(at)brturbo(dot)com(dot)br wrote:
> >> If you can keep your numbers of clients down below the critical
> >> level, you should find the overall workload is fine.
> >
> > We have at about 600 connections. Is this a case to use a connection
> > pool (pg_pool) system?
>
> Possibly - that should help. I'm assuming that most of your queries are
> very short, so you could probably get that figure down a lot lower.
> You'll keep the same amount of queries running through the system, just
> queue them up.
that have
Ah, yes, now that you mention, avoid running many queries with a
similiar timing behaviour, PG8 seems to have a lock design that's very
bad for the memory architecture of the Xeons.
So running SELECT * FROM table WHERE id=1234567890; from 600 clients in
parallel can be quite bad than say a complicated 6-way join :(
Andreas
>
> > And why this happens only with 8.0 and 8.1 and not with the 7.4?
>
> Not sure. Maybe 8.x is making more intensive use of your memory,
> possibly with a change in your plans.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2006-11-03 19:04:34 | EXISTS optimization |
Previous Message | Jonah H. Harris | 2006-11-03 15:27:28 | Re: profiling PL/pgSQL? |