From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Recording test runtimes with the buildfarm |
Date: | 2020-06-10 21:56:45 |
Message-ID: | 26413.1591826205@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Thu, 11 Jun 2020 at 02:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I have in the past scraped the latter results and tried to make sense of
>> them. They are *mighty* noisy, even when considering just one animal
>> that I know to be running on a machine with little else to do.
> Do you recall if you looked at the parallel results or the serially
> executed ones?
> I imagine that the parallel ones will have much more noise since we
> run the tests up to 20 at a time. I imagine probably none, or at most
> not many of the animals have enough CPU cores not to be context
> switching a lot during those the parallel runs. I thought the serial
> ones would be better but didn't have an idea of they'd be good enough
> to be useful.
I can't claim to recall specifically, but I agree with your theory
about that, so I probably looked at the serial-schedule case.
Note that this is moot for animals using use_installcheck_parallel
... but it looks like that's still just a minority of them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-06-10 22:00:15 | Re: Recording test runtimes with the buildfarm |
Previous Message | Thomas Munro | 2020-06-10 21:43:43 | Re: Recording test runtimes with the buildfarm |