From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org,Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Reporting script runtimes in pg_regress
Date: Sun, 10 Feb 2019 09:44:29 +0530
Message-ID: <B77F5155-D9EC-4142-AF87-B220A983B754@anarazel.de> (raw)
In-Reply-To: <16646.1549770618@sss.pgh.pa.us>
References: <16646.1549770618@sss.pgh.pa.us>
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 up with a schedule that's optimized.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us
Subject: Re: Reporting script runtimes in pg_regress
In-Reply-To: <B77F5155-D9EC-4142-AF87-B220A983B754@anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox