Not exactly, I think.
It said that postgresql "Add code to detect an SMP machine and handle
spinlocks accordingly", so it is an issue of spinlock handling, not the distribution
of execution tree.
In SMP enviorment, when using spinlock, when we fail to get the spin lock at a
time, we may do a number of null loops to try to see if another threads on another cpu
release the spin lock. It is just like M$'s EnterCriticalSection system call's last
parameter.
Am I right?
======= 2003-09-24 00:09:00 You Wrote: =======
>On Tue, 2003-09-23 at 22:45, Li YueXin wrote:
>> I found postgresql running on the multi CPU machine doesn't have
>> better performance than single CPU machine. Can you explain the
>> reason?
>
>In addition to what Christopher Browne suggests, keep in mind that
>PostgreSQL spawns a separate Unix process for each client connection.
>Since each process can run on at most one CPU at any given time, if the
># of concurrent queries your application submits is < than the # of CPUs
>in the machine, PostgreSQL won't take advantage of all your CPUs.
>
>It would be possible to spread the execution of a single query over
>multiple CPUs (say, have different nodes in the query tree execute on
>different CPUs concurrently), but I highly doubt PostgreSQL will bother
>doing that anytime soon.
>
>-Neil
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
= = = = = = = = = = = = = = = = = = = =
Yours Sincerely,
Hu Tian-Lei
[EMAIL PROTECTED]
2003-09-24
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
