|
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@xxxxxxxxxxxxxx > From: holger@xxxxxxxxxx > 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx) > 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! |
