Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: New to PostgreSQL, performance considerations


  • From: "Bucky Jordan" <bjordan(at)lumeta(dot)com>
  • To: "Ron" <rjpeace(at)earthlink(dot)net>, "Cosimo Streppone" <cosimo(at)streppone(dot)it>
  • Cc: "Postgresql Performance list" <pgsql-performance(at)postgresql(dot)org>
  • Subject: Re: New to PostgreSQL, performance considerations
  • Date: Wed, 13 Dec 2006 13:49:52 -0500
  • Message-id: <78ED28FACE63744386D68D8A9D1CF5D420A2B2(at)MAIL(dot)corp(dot)lumeta(dot)com>

> 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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group