Re: performance-test farm - Mailing list pgsql-hackers

From Tom Lane
Subject Re: performance-test farm
Date
Msg-id 15311.1305210983@sss.pgh.pa.us
Whole thread Raw
In response to Re: performance-test farm  (Stephen Frost <sfrost@snowman.net>)
Responses Re: performance-test farm  (Tomas Vondra <tv@fuzzy.cz>)
Re: performance-test farm  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
> * Josh Berkus (josh@agliodbs.com) wrote:
>> The first problem is plaform performance, which would be a matter of
>> expanding the buildfarm to include a small set of performance tests ...
>> probably ones based on previously known problems, plus some other simple
>> common operations.  The goal here would be to test on as many different
>> machines as possible, rather than getting full coverage of peformance.

I think it's a seriously *bad* idea to expect existing buildfarm members
to produce useful performance data.  Very few of them are running on
dedicated machines, and some are deliberately configured with
performance-trashing options.  (I think just about all of 'em use
--enable-cassert, but there are some with worse things...)

We can probably share a great deal of the existing buildfarm code and
infrastructure, but the actual members of the p-farm will need to be a
separate collection of machines running different builds.

Stephen Frost <sfrost@snowman.net> writes:
> imv, we should be trying to include the above in the regression tests,
> presuming that they can be done in that structure and that they can be
> done 'quickly'.

There's no such thing as a useful performance test that runs quickly
enough to be sane to incorporate in our standard regression tests.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Infinity bsearch crash on Windows
Next
From: "MauMau"
Date:
Subject: Fw: [BUGS] BUG #6011: Some extra messages are output in the event log at PostgreSQL startup