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