This is how multiprocessor systems work. You will benefit from the second processor when you run another query in paralell. There is no way as far as I am aware to run single task on both processors (except maybe by using threads?) By the way, Intel processor's Hyperthreading provides not two CPU's per one, but sort of one and a half. The 'second' CPU is not fully functional (some parts of the processor are not doubled) so you may indeed get better performance for CPU intensive applications by disabling Hyperthreading. This is because, if the OS can't known what you are going to do with the CPU, it may/will schedule it for the 'half' CPU and it will wait for the respective unit becoming 'ready' from time to time. There is a new varint, Pentium D processors that are 'dual core' and provide what Hyperthreading was acutllay promissing - two CPUs in one chip. Don not worry about the 25% - you are actually using 50% of your threorethical CPU power and 100% of the processing a single CPU can give you - you still benefit from the multiprocessing, because, one processor runs your query, while another is servicing the operating system functions, including I/O etc. Daniel > Hi, > > The FreeBSD 6.0 SMP Kernel recognizes my two XEONS as 4 CPUs. > > A single postgresql query, as I could see in the top utility, can use a > maximum of 25% of CPU time, since it runs on one single virtual CPU, > which means for me "half of a XEON". Is that correct? > > If yes, is there a way to change that, and accelerate long queries > (which are all CPU-bound) in giving them more processing time, like a > full XEON? Both XEONS? Should I disable Hyperthreading for that? > > Thanks, > > ---------------------------------- > Philippe Lang > Attik System > rte de la Fonderie 2 > 1700 Fribourg > Switzerland > http://www.attiksystem.ch > > Tel: +41 (26) 422 13 75 > Fax: +41 (26) 422 13 76 > GSM: +41 (79) 351 49 94 > Email: philippe.lang@xxxxxxxxxxxxxx > Skype: philippe.lang > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
