> > Just to be a pain, the only benchmarks I've seen (OSDL) indicates 8.0 is
> > a touch slower than 7.4.
> >
> > It is, however, significantly more predictable (consistent) in it's
> > performance -- which is far more important for most of us.
> >
>
> Interesting. Worrying and interesting. Could I ask you to clarify this in
> significantly more detail, so we can all discuss this? I'm willing to listen
> to the evidence - there need be no heated debate.
>
> Are you saying that:
> - 8.0 is slower than 7.4, for all workloads
> - when you give 8.0 more CPUs, it is less or at least similarly scalable as
> 7.4.5?
I cannot answer these because I've not tested all workloads under
different configurations. For my workload on 2 to 4way machines, Pg on
8.0 configured similarly to 7.4 was a touch slower (5% or so). I had
read Mark Wong of OSDL has found similar results for a straight upgrade
-- but I don't believe they've done specific testing to confirm this. A
few other parameters had been changed (test duration being a big one).
Anyway, for me, instead of queries taking between 2ms and 150ms, 8.0 is
more consistent to be between 3ms and 5ms (numbers made up to
demonstrate consistency). But if you got 2ms 300 times for every 150ms
execution time, 7.4 was technically faster.
> Are you really sure a fully comparable test has taken place? Have you taken
> into account the effect of tablespaces - or do you consider that to be a
> "dressing-up" of something that was already possible?
If you do take advantage of these features (putting WAL on a separate
LUN, etc.) then you can gain that time back again.
Of course, there's also the bug-fix performance boosts (int4 to int8
joins) which will make a huge difference for some users.
