Mindaugas Riauba wrote:
> > > I missed your orig. post, but AFAIK multiprocessing kernels will handle
> > > 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
> > > process uses more than one cpu), but overall multi-query performance has
> > > 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
> scheduler will run 2 processes on the same real cpu. And I read that there
> patches for Linux kernel to fix that. Sooner rather than later they will
> 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