| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
| 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 04:43:14 |
| Message-ID: | 1058.1153716194@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2006-07-24 05:15:03 | Re: Adding a pgbench run to buildfarm |
| Previous Message | Bort, Paul | 2006-07-24 04:40:35 | Re: Adding a pgbench run to buildfarm |