Mindaugas Riauba wrote: > > > > I missed your orig. post, but AFAIK multiprocessing kernels will handle > HT > > > CPUs as 2 CPUs each. Thus, our dual Xeon 2.4 is recognized as 4 Xeon 2.4 > > > CPUs. > > > > > > This way, I don't think HT would improve any single query (afaik no > postgres > > > process uses more than one cpu), but overall multi-query performance has > to > > > improve. > > > > When you use hyperthreading, each virtual cpu runs at 70% of a full CPU, > > so hyperthreading could be slower than non-hyperthreading. On a fully > > loaded dual cpu system, you are looking at 2.8 cpu's (0.70 * 4), while > > if it isn't loaded, you are looking at slowing down if you are only > > using 1 or 2 cpu's. > > Virtual cpus are not running at 70% of real cpus :). Slowdown will happen > if > scheduler will run 2 processes on the same real cpu. And I read that there > are > patches for Linux kernel to fix that. Sooner rather than later they will > appear > in Linus kernel.
Right, I simplified it. The big deal is whether the OS favors the second real CPU over one of the virtual CPU's on the same die --- by default, it doesn't. Ever if it did work perfectly, you are talking about going from 1 to 1.4 or 2 to 2.8, which doesn't seem like much. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(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
