Re: Finding bottleneck

From: Merlin Moncure
Subject: Re: Finding bottleneck
Date: ,
Msg-id: 6EE64EF3AB31D5448D0007DD34EEB3417DD153@Herge.rcsinc.local
(view: Whole thread, Raw)
In response to: Finding bottleneck  (Kari Lavikka)
List: pgsql-performance

Tree view

Finding bottleneck  (Kari Lavikka, )
 Re: Finding bottleneck  (Gavin Sherry, )
 Re: Finding bottleneck  (Claus Guttesen, )
 Re: Finding bottleneck  ("Merlin Moncure", )
 Re: Finding bottleneck  ("Luke Lonergan", )
  Re: Finding bottleneck  (Kari Lavikka, )
   Re: Finding bottleneck  (Tom Lane, )
 Re: Finding bottleneck  ("Merlin Moncure", )
  Re: Finding bottleneck  (Tom Lane, )
  Re: Finding bottleneck  (Kari Lavikka, )
   Re: Finding bottleneck  (Tom Lane, )
    Re: Finding bottleneck  (Kari Lavikka, )
     Re: Finding bottleneck  (Tom Lane, )
    Re: Finding bottleneck  (Kari Lavikka, )
     Re: Finding bottleneck  (Tom Lane, )
 Re: Finding bottleneck  (Ron, )
 Re: Finding bottleneck  ("Merlin Moncure", )
  Re: Finding bottleneck  (Tom Lane, )
 Re: Finding bottleneck  ("Merlin Moncure", )
 Re: Finding bottleneck  ("Merlin Moncure", )
  Re: Finding bottleneck  (Tom Lane, )
 Re: Finding bottleneck  ("Merlin Moncure", )

> 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:

From: Mark Cotner
Date:
Subject: Re: sustained update load of 1-2k/sec
From: Dan Harris
Date:
Subject: Re: Query plan looks OK, but slow I/O - settings advice?