Re: Adding a pgbench run to buildfarm

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

In response to

Browse pgsql-hackers by date

  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