Re: Reporting script runtimes in pg_regress

Hi,

On February 10, 2019 9:20:18 AM GMT+05:30, Tom Lane  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.