Re: Recording test runtimes with the buildfarm

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.

In response to

Responses

Browse pgsql-hackers by date

  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