> 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