Re: [HACKERS] distributed performance testing

2005-08-22 Thread Jim C. Nasby
On Mon, Aug 22, 2005 at 02:28:54PM -0700, Darcy Buskermolen wrote: > On Monday 22 August 2005 13:13, Jim C. Nasby wrote: > > Of course we could use pgbench for this instead of dbt*, but ISTM that > > dbt is a better choice since it's useful for a broader set of people. > > The downside is it requir

Re: [HACKERS] distributed performance testing

2005-08-22 Thread Darcy Buskermolen
On Monday 22 August 2005 13:13, Jim C. Nasby wrote: > On Sat, Aug 13, 2005 at 06:29:58PM -0400, Tom Lane wrote: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > Incidentally, use of a different SCM system might well make > > > constructing test sets more simple. Imagine, say, in SVN, you would

Re: [HACKERS] distributed performance testing

2005-08-22 Thread Jim C. Nasby
On Sat, Aug 13, 2005 at 06:29:58PM -0400, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > Incidentally, use of a different SCM system might well make > > constructing test sets more simple. Imagine, say, in SVN, you would > > create a branch called "test-set--mm-dd" or some

Re: [HACKERS] distributed performance testing

2005-08-13 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Incidentally, use of a different SCM system might well make constructing test sets more simple. Imagine, say, in SVN, you would create a branch called "test-set--mm-dd" or some such, make your changes there, add a test scrip

Re: [HACKERS] distributed performance testing

2005-08-13 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Incidentally, use of a different SCM system might well make > constructing test sets more simple. Imagine, say, in SVN, you would > create a branch called "test-set--mm-dd" or some such, make your > changes there, add a test script under some wel

[HACKERS] distributed performance testing

2005-08-13 Thread Andrew Dunstan
A little while ago I rather rashly opined that we could extend the buildfarm to do (optional) performance testing. After thinking about it for some time I now think that might not be such a good idea. We can certainly leverage a lot of the technology used and experience gained in building the