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.
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 |