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
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 |