Re: pgbench Comparison of 7.4.7 to 8.0.2

From: Thomas F(dot)O'Connell <tfo(at)sitening(dot)com>
To: Steve Poe <spoe(at)sfnet(dot)cc>
Cc: PgSQL - Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: pgbench Comparison of 7.4.7 to 8.0.2
Date: 2005-04-24 02:33:00
Message-ID: a7d01e3672a76f528ac59207627ce69f@sitening.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Steve,

Per your and Tom's recommendations, I significantly increased the
number of transactions used for testing. See my last post.

The database will have pretty heavy mixed use, i.e., both reads and
writes.

I performed 32 iterations per scenario this go-round.

I'll look into OSDB for further benchmarking. Thanks for the tip.

Since pgbench is part of the postgres distribution and I had it at hand
and it seems to be somewhat widely referenced, I figured I go ahead and
post preliminary results from it.

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Apr 15, 2005, at 4:24 PM, Steve Poe wrote:

> Tom,
>
> People's opinions on pgbench may vary, so take what I say with a grain
> of salt. Here are my thoughts:
>
> 1) Test with no less than 200 transactions per client. I've heard with
> less than this, your results will vary too much with the direction of
> the wind blowing. A high enough value will help rule out some "noise"
> factor. If I am wrong, please let me know.
>
>
> 2) How is the database going to be used? What percentage will be
> read/write if you had to guess? Pgbench is like a TPC-B with will help
> guage the potential throughput of your tps. However, it may not stress
> the server enough to help you make key performance changes. However,
> benchmarks are like statistics...full of lies <g>.
>
> 3) Run not just a couple pgbench runs, but *many* (I do between 20-40
> runs) so you can rule out noise and guage improvement on median
> results.
>
> 4) Find something that you test OLTP-type transactions. I used OSDB
> since it is simple to implement and use. Although OSDL's OLTP testing
> will closer to reality.
>
> Steve Poe

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-04-24 04:48:59 Re: [HACKERS] Bad n_distinct estimation; hacks suggested?
Previous Message Thomas F.O'Connell 2005-04-24 02:31:13 Re: pgbench Comparison of 7.4.7 to 8.0.2