From: | "Bort, Paul" <pbort(at)tmwsystems(dot)com> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding a pgbench run to buildfarm |
Date: | 2006-07-24 16:46:54 |
Message-ID: | DB106B1B5B8F734B8FF3E155A3A556C202D4FD5E@clemail1.tmwsystems.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
> We are really not going to go in this direction. If you want ideal
> performance tests then a heterogenous distributed collection of
> autonomous systems like buildfarm is not what you want.
>
> You are going to have to live with the fatc that there will be
> occasional, possibly even frequent, blips in the data due to other
> activity on the machine.
>
> If you want tightly controlled or very heavy load testing this is the
> wrong vehicle.
>
> You might think that what that leaves us is not worth having - the
> consensus in Toronto seemed to be that it is worth having,
> which is why
> it is being pursued.
>
I wasn't at the conference, but the impression I'm under is that the
point of this isn't to catch a change that causes a 1% slowdown; the
point is to catch much larger problems, probably 20% slowdown or more.
Given the concerns about running this on machines that don't have a lot
of CPU and disk to spare, should it ship disabled?
Andrew, what do you think of pgbench reports shipping separately? I have
no idea how the server end is set up, so I don't know how much of a pain
that would be.
Regards,
Paul Bort
P.S. My current thought for settings is scaling factor 10, users 5,
transactions 1000.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-07-24 16:49:57 | Re: plPHP and plRuby |
Previous Message | Tom Lane | 2006-07-24 16:46:52 | Re: Resurrecting per-page cleaner for btree |