Date: Sun, 10 Feb 2019 09:44:29 +0530
User-Agent: K-9 Mail for Android
In-Reply-To: <16646.1549770618@sss.pgh.pa.us>
References: <16646.1549770618@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Reporting script runtimes in pg_regress
To: pgsql-hackers@lists.postgresql.org,Tom Lane <tgl@sss.pgh.pa.us>
From: Andres Freund <andres@anarazel.de>
Message-ID: <B77F5155-D9EC-4142-AF87-B220A983B754@anarazel.de>
Precedence: bulk

Hi,

On February 10, 2019 9:20:18 AM GMT+05:30, Tom Lane <tgl@sss=2Epgh=2Epa=2E=
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=2E
>
>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=2E  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                        =2E=2E=2E ok (35 ms)
>     lseg                         =2E=2E=2E ok (31 ms)
>     line                         =2E=2E=2E ok (23 ms)
>     box                          =2E=2E=2E ok (135 ms)
>     path                         =2E=2E=2E ok (24 ms)
>     polygon                      =2E=2E=2E ok (1256 ms)
>     circle                       =2E=2E=2E ok (20 ms)
>     date                         =2E=2E=2E ok (69 ms)
>     time                         =2E=2E=2E ok (40 ms)
>     timetz                       =2E=2E=2E ok (22 ms)
>     timestamp                    =2E=2E=2E ok (378 ms)
>     timestamptz                  =2E=2E=2E ok (378 ms)
>     interval                     =2E=2E=2E ok (50 ms)
>     inet                         =2E=2E=2E ok (56 ms)
>     macaddr                      =2E=2E=2E ok (33 ms)
>     macaddr8                     =2E=2E=2E ok (37 ms)
>     tstypes                      =2E=2E=2E 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                     =2E=2E=2E ok (3807 ms)
>     partition_join               =2E=2E=2E ok (10433 ms)
>     partition_prune              =2E=2E=2E ok (19370 ms)
>     reloptions                   =2E=2E=2E ok (1166 ms)
>     hash_part                    =2E=2E=2E ok (628 ms)
>     indexing                     =2E=2E=2E ok (22070 ms)
>     partition_aggregate          =2E=2E=2E ok (12731 ms)
>     partition_info               =2E=2E=2E ok (1373 ms)
>test event_trigger                =2E=2E=2E ok (1953 ms)
>test fast_default                 =2E=2E=2E ok (2689 ms)
>test stats                        =2E=2E=2E ok (1173 ms)
>
>Does anyone else feel that this is interesting/useful data?

Yes, it does=2E I've locally been playing with parallelizing isolationtest=
er's schedule, and it's quite useful for coming up with a schedule that's o=
ptimized=2E

Andres
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E