From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org,David Rowley <dgrowleyml(at)gmail(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 22:00:16 |
Message-ID: | 8E220004-2396-49BA-88CD-47A26871E4D3@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On June 10, 2020 2:13:51 PM PDT, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>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'd assume that a rolling average (maybe 10 runs or so) would hide noise enough to see at least some trends even for parallel runs.
We should be able to prototype this with a few queries over the bf database, right?
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-10 22:02:20 | Re: Recording test runtimes with the buildfarm |
Previous Message | Thomas Munro | 2020-06-10 22:00:15 | Re: Recording test runtimes with the buildfarm |