Re: Finding bottleneck - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Finding bottleneck
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3417DD153@Herge.rcsinc.local
Whole thread Raw
In response to Finding bottleneck  (Kari Lavikka <tuner@bdb.fi>)
List pgsql-performance
> 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



pgsql-performance by date:

Previous
From: "J. Andrew Rogers"
Date:
Subject: Re: sustained update load of 1-2k/sec
Next
From: John A Meinel
Date:
Subject: Re: extremly low memory usage