Re: TAP tests take a long time

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: TAP tests take a long time
Date: 2017-04-12 19:41:23
Message-ID: 20170412194123.GL9812@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew,

* Andrew Dunstan (andrew(dot)dunstan(at)2ndquadrant(dot)com) wrote:
> On 04/12/2017 08:40 AM, Andrew Dunstan wrote:
> > On 04/12/2017 01:27 AM, Craig Ringer wrote:
> >> BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can
> >> collect more data from the buildfarm on what takes a while. Sample
> >> output:
> >
> > I'll add that to the commandline the buildfarm uses in the upcoming release.
>
> See
> <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2017-04-12%2013%3A54%3A22>
>
> One thing I noticed was this
>
> [10:02:40] t/001_basic.pl ......... ok 320 ms
> [10:02:59] t/002_pg_dump.pl ....... ok 19441 ms
> [10:03:47] t/010_dump_connstr.pl .. ok 47430 ms
>
> Why does the last test set take 47s?

It's doing a bunch of dropdb/createdb stuff, and also creates multiple
clusters. Part of this is because it's generating random names for
databases to make sure they are handled correctly. I'd certainly love
to see it take less time but I've not really done very much with it.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-04-12 19:43:05 Re: [pgsql-www] Small issue in online devel documentation build
Previous Message Tom Lane 2017-04-12 19:35:54 Re: Inadequate parallel-safety check for SubPlans