Re: distributed performance testing

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Darcy Buskermolen <darcy(at)wavefire(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: distributed performance testing
Date: 2005-08-22 22:14:07
Message-ID: 20050822221407.GK72767@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 22, 2005 at 02:28:54PM -0700, Darcy Buskermolen wrote:
> On Monday 22 August 2005 13:13, Jim C. Nasby wrote:
> > Of course we could use pgbench for this instead of dbt*, but ISTM that
> > dbt is a better choice since it's useful for a broader set of people.
> > The downside is it requires dbt, but that doesn't seem to be a major
> > issue. Also, using dbt means we can test different use cases (dbt2 ~=
> > TPC-C, dbt3 ~= TPC-H, etc), while pgbench is just a single benchmark.
>
> And there is always http://pgfoundry.org/projects/tpc-w-php/ for a ~= TPC-W
> workload.

True, but then you don't get TPC-C, and dbt1 is ~= TPC-W. So with a
package of the full dbt suite (doesn't exist yet, but I suspect it
wouldn't be hard to change that), you get W, C, H, and eventually
TPC-App. Plus, much of what needs to be developed for our use-case would
benefit all dbt users, whereas pgbench is only of use to us internally.
dbt is also more flexable, since you can vary workload ratios. For
example, you can run dbt2 in a 90% read environment if you wanted.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-08-22 22:18:25 Re: beginning hackers
Previous Message Bruce Momjian 2005-08-22 22:08:05 Re: enable_constraint_exclusion GUC name