Re: Best way to load test a postgresql server

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Shaul Dar <shauldar(at)gmail(dot)com>
Cc: Peter Sheats <psheats(at)pbpost(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Best way to load test a postgresql server
Date: 2009-06-03 23:01:32
Message-ID: alpine.GSO.2.01.0906031854270.27272@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 2 Jun 2009, Shaul Dar wrote:

> If you want to test the H/W and configuration of your DBMS then you can
> use the pgbench tool (which uses a specific built-in DB+schema,
> following the TPC benchmark).

There are a lot of TPC benchmarks. pgbench simulates TPC-B (badly), which
is a benchmark from 1990. It's not at all representative of the current
TPC benchmarks.

> If you want to load test your own specific DB then I am unaware of any
> such tools.

pgbench will run against any schema and queries, the built-in set are just
the easiest to use. I just released a bunch of slides and a package I
named pgbench-tools that show some of the possibilities here, links to
everything are at:
http://notemagnet.blogspot.com/2009/05/bottom-up-postgresql-benchmarking-and.html

I'd mentioned working on that this before on this list but the code just
got stable enough to release recently. Anybody who is running lots of
pgbench tests at different database sizes and client loads might benefit
from using my toolset to automate running the tests and reporting on the
results.

The last few slides of my pgbench presentation show how you might write a
custom test that measures how fast rows of various sizes can be inserted
into your database at various client counts.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2009-06-04 01:21:24 Re: Pointers needed on optimizing slow SQL statements
Previous Message Janine Sisk 2009-06-03 22:04:47 Re: Pointers needed on optimizing slow SQL statements