> HT off is common knowledge for better benchmarking result It's wise to use the qualifer 'for better benchmarking results'. It's worth keeping in mind here that a benchmark is not the same as normal production use. For example, where I work we do lots of long-running queries in parallel over a big range of datasets rather than many short-term transactions as fast as possible. Our biggest DB server is also used for GDAL work and R at the same time*. Pretty far from pgbench; not everyone is constrained by locks. I suppose that if your code is basically N copies of the same function, hyper-threading isn't likely to help much because it was introduced to allow different parts of the processor to be used in parallel when you're running hetarogenous code. But if you're hammering just one part of the CPU... well, adding another layer of logical complexity for your CPU to manage probably isn't going to do much good. Should HT be on or off when you're running 64 very mixed types of long-term queries which involve variously either heavy use of real number calculations or e.g. logic/string handling, and different data sets? It's a much more complex question than simply maxing out your pgbench scores. I don't have the data now unfortunately, but I remember seeing a benefit for HT on our 4 core e3 when running GDAL/Postgis work in parallel last year. It's not surprising though; the GDAL calls are almost certainly using different functions of the processor compared to postgres and there should be very little lock contention. In light of this interesting data I'm now leaning towards proposing HT off for our mapservers (which receive short, similar requests over and over), but for the hetaragenous servers, I think I'll keep it on for now. Graeme. * unrelated. There's also huge advantages for us in keeping these different programs running on the same machine since we found we can get much better transfer rates through unix sockets than with TCP over the network. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
