I think you are not right with remark about threads...
At least with Sun Solaris you will be much faster with multithreaded
process vs multi processes.
Why? Because Solaris is real multithreaded kernel, so it sees only
threads in the kernel level.
"Process" is a user view for running task, and 1 process = at least 1
Why multithreaded process wil be faster than multi processes? - Because
switching between threads will cost much less than between processes, so
you wil have more CPU time to continue your job.
And, of course, all threads can use any CPU, so you win more with more
CPU(s), but even with ONE CPU on your machine you will be faster with 10
threads than with 10 processes...
Just my 0.02c about Solaris :)
Bruce Momjian wrote:
> > > P.S. From previous posts, I'm starting to think that
> > > there is a VAST misconception that a single-threaded
> > > database engine (which is what Oracle was until some
> > > version 7 releases, I believe, called Oracle MTS
> > > appeared) can only handle ONE query at a time, and
> > > does
> > > not exec() a child process for each connection.
> > > Someone ought to start the propoganda of claiming
> > > multi-threaded DBMS as "single process" servers.
> > Yes, I am totally unsure how this gets confused by people. I am going
> > to put it int the FAQ.
> > Yes, and I agree that most multi-threaded DBMS are "single process",
> > which can't make use if multiple cpus, except on some very special OS's
> > that allow threads to move between cpus, sometimes called kernel
> > threads, I think, but I am not sure on that.
> I have added this to the FAQ:
> We handle each user connection by creating a Unix process. Backend
> processes share data buffers and locking information. With multiple
> CPU's, multiple backends can easily run on different CPU's. Unlike
> PostgreSQL, databases that use process threads have multiple users
> connections running in the same Unix process. This makes it difficult
> for them to utlilize multiple CPU's.
> Bruce Momjian | http://www.op.net/~candle
> maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Dimitri KRAVTCHUK (dim) Sun Microsystems
Benchmark Engineer France
In response to
pgsql-general by date
|Next:||From: Jay Bloodworth||Date: 1999-08-29 22:52:11|
|Subject: SERIAL vs. OIDs|
|Previous:||From: Ross J. Reedstrom||Date: 1999-08-28 05:03:42|
|Subject: Re: [GENERAL] 6.5.1 pg_dump adds "connect as" line|