> Cool --- we've done a fair amount of work on squeezing out internal
> inefficiencies during this devel cycle, but it's always hard to
predict
> just how much anyone will notice in the real world.
>
> Care to do some oprofile or gprof profiles to see where it's still
bad?
>

Since release of 8.0, we are a strictly windows shop . I tried
building pg with -pg flag and got errors in some of the satellite
libraries. I think this is solvable though at some point I'll spend
more time on it. Anyways, just so you know the #s that I'm seein, I've
run several benchmarks of various programs that access pg via our ISAM
bridge. The results are as consistent as they are good. These tests
are on the same box using the same .conf on the same freshly loaded
data. The disk doesn't play a major role in these tests. All data
access is through ExecPrepared libpq C interface. Benchmark is run from
a separate box on a LAN.

Bill of Materials Traversal ( ~ 62k records).

ISAM* pg 8.0 pg 8.1 devel delta 8.0->8.1
running time 63 sec 90 secs 71 secs 21%
cpu load 17% 45% 32% 29%
loadsecs** 10.71 40.5 22.72 44%
recs/sec 984 688 873
recs/loadsec 5882 1530 2728

*ISAM is an anonymous commercial ISAM library in an optimized server
architecture (pg smokes the non-optimized flat file version).
**Loadsecs being seconds of CPU at 100% load.


IOW cpu load drop is around 44%. Amazing!

Merlin



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster