Re: performance-test farm

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: performance-test farm
Date: 2011-05-12 16:07:36
Message-ID: 4DCC05C8.5090809@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> There's no such thing as a useful performance test that runs quickly
> enough to be sane to incorporate in our standard regression tests.
>

To throw a hard number out: I can get a moderately useful performance
test on a SELECT-only workload from pgbench in about one minute. That's
the bare minimum, stepping up to 5 minutes is really necessary before
I'd want to draw any real conclusions.

More importantly, a large portion of the time I'd expect regression test
runs to be happening with debug/assert on. We've well established this
trashes pgbench performance. One of the uglier bits of code added to
add the "performance farm" feature to the buildfarm code was hacking in
a whole different set of build options for it.

Anyway, what I was envisioning here was that performance farm systems
would also execute the standard buildfarm tests, but not the other way
around. We don't want performance numbers from some platform that is
failing the basic tests. I would just expect that systems running the
performance tests would cycle through regression testing much less
often, as they might miss a commit because they were running a longer
test then.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-05-12 17:04:38 Re: pg_upgrade and PGPORT
Previous Message Tom Lane 2011-05-12 15:59:50 Re: Fix for bug in ldapServiceLookup in libpq