Re: Reporting script runtimes in pg_regress

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Reporting script runtimes in pg_regress
Date: 2019-02-10 04:14:29
Message-ID: B77F5155-D9EC-4142-AF87-B220A983B754@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On February 10, 2019 9:20:18 AM GMT+05:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>I've wondered for some time whether we couldn't make a useful
>reduction in the run time of the PG regression tests by looking
>for scripts that run significantly longer than others in their
>parallel groups, and making an effort to trim the runtimes of
>those particular scripts.
>
>The first step in that of course is to get some data, so attached
>is a patch to pg_regress to cause it to print the runtime of each
>script. This produces results like, say,
>
>parallel group (17 tests): circle line timetz path lseg point macaddr
>macaddr8 time interval inet tstypes date box timestamp timestamptz
>polygon
> point ... ok (35 ms)
> lseg ... ok (31 ms)
> line ... ok (23 ms)
> box ... ok (135 ms)
> path ... ok (24 ms)
> polygon ... ok (1256 ms)
> circle ... ok (20 ms)
> date ... ok (69 ms)
> time ... ok (40 ms)
> timetz ... ok (22 ms)
> timestamp ... ok (378 ms)
> timestamptz ... ok (378 ms)
> interval ... ok (50 ms)
> inet ... ok (56 ms)
> macaddr ... ok (33 ms)
> macaddr8 ... ok (37 ms)
> tstypes ... ok (62 ms)
>
>or on a rather slower machine,
>
>parallel group (8 tests): hash_part reloptions partition_info identity
>partition_join partition_aggregate partition_prune indexing
> identity ... ok (3807 ms)
> partition_join ... ok (10433 ms)
> partition_prune ... ok (19370 ms)
> reloptions ... ok (1166 ms)
> hash_part ... ok (628 ms)
> indexing ... ok (22070 ms)
> partition_aggregate ... ok (12731 ms)
> partition_info ... ok (1373 ms)
>test event_trigger ... ok (1953 ms)
>test fast_default ... ok (2689 ms)
>test stats ... ok (1173 ms)
>
>Does anyone else feel that this is interesting/useful data?

Yes, it does. I've locally been playing with parallelizing isolationtester's schedule, and it's quite useful for coming up with a schedule that's optimized.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2019-02-10 05:24:31 Re: Transaction commits VS Transaction commits (with parallel) VS query mean time
Previous Message Peter Geoghegan 2019-02-10 03:54:37 Re: Reporting script runtimes in pg_regress