> What I find interesting is that so far Guido's C2D Mac laptop has > gotten the highest values by far in this set of experiments, and no > one else is even close. > The slowest results, Michael's, are on the system with what appears > to be the slowest CPU of the bunch; and the ranking of the rest of > the results seem to similarly depend on relative CPU > performance. This is not what one would naively expect when benching > a IO intensive app like a DBMS. > > Given that the typical laptop usually has 1 HD, and a relatively > modest one at that (the fastest available are SATA 7200rpm or > Seagate's perpendicular recording 5400rpm) in terms of performance, > this feels very much like other factors are bottlenecking the > experiments to the point where Daniel's results regarding compiler > options are not actually being tested. > > Anyone got a 2.33 GHz C2D box with a decent HD IO subsystem more > representative of a typical DB server hooked up to it? I've only seen pg_bench numbers > 2,000 tps on either really large hardware (none of the above mentioned comes close) or the results are in memory due to a small database size (aka measuring update contention). Just a guess, but these tests (compiler opts.) seem like they sometimes show a benefit where the database is mostly in RAM (which I'd guess many people have) since that would cause more work to be put on the CPU/Memory subsystems. Other people on the list hinted at this, but I share their hypothesis that once you get IO involved as a bottleneck (which is a more typical DB situation) you won't notice compiler options. I've got a 2 socket x 2 core woodcrest poweredge 2950 with a BBC 6 disk RAID I'll run some tests on as soon as I get a chance. I'm also thinking for this test, there's no need to tweak the default config other than maybe checkpoint_segments, since I don't really want postgres using large amounts of RAM (all that does is require me to build a larger test DB). Thoughts? Thanks, Bucky
