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