From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bort, Paul" <pbort(at)tmwsystems(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Adding a pgbench run to buildfarm |
Date: | 2006-07-24 05:15:03 |
Message-ID: | 44C45757.4090105@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> Scale factor 10 produces an accounts table of about 130 Mb. Given that
>> most HW these days has at least 1G of ram, this probably means not much
>> retrieval IO is tested (only checkpoint and wal fsync). Do we want to
>> try 100 or even 200? (or recommend scale factor such that size > ram)?
>
> That gets into a different set of questions, which is what we want the
> buildfarm turnaround time to be like. The faster members today produce
> a result within 10-15 minutes of pulling their CVS snaps, and I'd be
> seriously unhappy if that changed to an hour or three. Maybe we need to
> divorce compile/regression tests from performance tests?
>
>
Right - this leads to further questions like, what the performance
testing on the buildfarms is actually for. If it is mainly to catch
regressions introduced by any new code, then scale factor 10 (i.e
essentially in memory testing) may in fact be the best way to show this up.
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2006-07-24 05:55:53 | Re: Adding a pgbench run to buildfarm |
Previous Message | Tom Lane | 2006-07-24 04:43:14 | Re: Adding a pgbench run to buildfarm |