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
spinlockhandling, 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
totry to see if another threads on another cpu release the spin lock. It is just like M$'s EnterCriticalSection system
call'slast 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
andy_hu@263.net
2003-09-24