From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, "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 12:38:37 |
Message-ID: | 44C4BF4D.8000600@dunslane.net |
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?
>
>
>
We could have the system report build/regression results before going on
to do performance testing. I don't want to divorce them altogether if I
can help it, as it will make cleanup a lot messier.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-07-24 13:59:35 | Re: On-disk bitmap index patch |
Previous Message | Tzahi Fadida | 2006-07-24 12:31:45 | Maximum size of tuples in a relation |