poor cpu utilization on dual cpu box

Folks,

I�m hoping someone can give me some pointers to resolving an issue with postgres and it�s ability to utilize multiple CPUs effectively.

The issue is that no matter how much query load we throw at our server it seems almost impossible to get it to utilize more than 50% cpu on a dual-cpu box.  For a single connection we can use all of one CPU, but multiple connections fail to increase the overall utilization (although they do cause it to spread across CPUs).

The platform is a dual CPU 2.8Ghz P4 Xeon Intel box (hyperthreading disabled)  running a fairly standard Redhat 9 distribution.  We are using postgres on this platform with a moderate sized data set (some hundreds of megs of data).  The tests perform no updates and simply hit the server with a single large complex query via a multithreaded java/jdbc client.  To avoid network distortion we run the client on the localhost (its cpu load is minimal).   We are running with shared buffers large enough to hold the entire database and sort memory of 64m, should easily be enough to prevent sorting to disk. 

At this point I�ve tried everything I can think of to diagnose this - checking the pg_locks table indicates that even under heavy load there are no ungranted locks, so it would appear not to be a locking issue.  Vmstat/iostat show no excessive figures for network or io waits.  The only outlandish figure is that context switches which spike up to 250,000/sec (seems large).  By all indications, postgres is waiting internally as if it is somehow singlethreaded.  However the documentation clearly indicates this should not be so.

Can anyone give me some pointers as to why postgres would be doing this?   Is postgres really multi-process capable or are the processes ultimately waiting on each other to run queries or access shared memory?

On a second note, has anyone got some tips on how to profile postgres in this kind of situation?  I have tried using gprof, but because postgres spawns its processes dynamically I always end up profiling the postmaster (not very useful).

Thanking in advance for any help!

Cheers,

Simon.

Ps. posted this to general, but then realised this is a better forum - sorry for the cross.