Hi,
On February 10, 2019 9:20:18 AM GMT+05:30, Tom Lane <tgl@sss.pgh.pa.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
upwith a schedule that's optimized.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.