That's it, we have 4 CPUs, each of which has 4 cores, that is we have 16 cores in total, but we have only 4 to 8 concurrent users, who regularly run complex queries. That is we can't use all our CPU resources in such a situation to speed up response time.
> To: pgsql-general@postgresql.org
> From: holger@wizards.de
> Subject: Re: [GENERAL] PostgreSQL process architecture question.
> Date: Tue, 9 Sep 2008 18:30:17 +0200
>
> On Tue, 09 Sep 2008 10:07:32 -0600, Scott Marlowe wrote:
>
> > On Tue, Sep 9, 2008 at 9:35 AM, Amber <guxiaobo1982@hotmail.com> wrote:
> >> We know PostgreSQL uses one dedicated server process to serve one client
> >> connection, what we want to know is whether PostgreSQL use multiple threads
> >> inside agents processes to take advantage of multiple CPUs. In our site we
> >> have only a few concurrent connections, so what occurs inside agent process
> >> is very important to us.
> >
> > No it doesn't. One connection gets one process which uses one CPU at a time.
>
> I understand the history/technical reasons/motivation for this, yet want
> to ask if anybod y has thought about using OpenMP for careful
> parallelization of per-process work sections? Scanning large (e.g. already
> locked) arrays, parallel sweeps or calculations might benefit from
> parallelizatoin without requiring a full-out threaded design. Such an
> approach could retain the per-process isolation model yet still reap
> multicore benefits. To boot OpenMP is pretty easy to use and comes with
> gcc.
>
> Since I don't know much about PG's internals and their data dependencies
> etc. this might well be a dumb idea, but I figured asking couldn't hurt. :)
>
> regards
> Holger
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
Try it!
