Re: Performance

From: Joshua Berkus <josh(at)agliodbs(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org, Tomas Vondra <tv(at)fuzzy(dot)cz>
Subject: Re: Performance
Date: 2011-04-29 04:58:33
Message-ID: 30006282.226917.1304053113799.JavaMail.root@mail-1.01.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

All,

> The easiest place to start is by re-using the work already done by the
> TPC for benchmarking commercial databases. There are ports of the TPC
> workloads to PostgreSQL available in the DBT-2, DBT-3, and DBT-5
> tests;

Also EAStress, which I think the project still has a license for.

The drawback to these is that they're quite difficult and time-consuming to run, making them unsuitable for doing, say, incremental tuning tests which need to run 100 iterations. At least, now that we don't have access to the OSDL or Sun labs anymore.

On the other hand, Greg has made the first steps in a benchmark constructor kit by making it possible for pgBench to run arbitrary workloads. Someone could build on Greg's foundation by:

a) building a more complex database model with random data generators, and
b) designing a wide series of queries designed to test specific performance problems, i.e, "large object reads", "complex nested subqueries", "mass bulk correllated updates"
c) finally creating scripts which generate benchmarks by choosing a database size and a "mix" of the query menu

This would give us kit which would be capable of testing performance regressions and improvements for PostgreSQL.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Qiang Wang 2011-04-29 07:13:08 Will shared_buffers crash a server
Previous Message Tomas Vondra 2011-04-29 00:22:09 Re: Performance