Re: slowest tap tests - split or accelerate? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: slowest tap tests - split or accelerate?
Date
Msg-id 540868.1642611241@sss.pgh.pa.us
Whole thread Raw
In response to Re: slowest tap tests - split or accelerate?  (Andres Freund <andres@anarazel.de>)
Responses Re: slowest tap tests - split or accelerate?
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-01-18 13:40:40 -0800, Andres Freund wrote:
>> Maybe we really should do at least the most simplistic caching for initdbs, by
>> doing one initdb as part of the creation of temp_install. Then Cluster::init
>> would need logic to only use that if $params{extra} is empty.

> I hacked this together. And the wins are bigger than I thought.

Me too ;-).  As I remarked earlier, I'd tried this once before and
gave up because it didn't seem to be winning much.  But that was
before we had so many initdb's triggered by TAP tests, I think.

I tried this patch on florican's host, which seems mostly disk-bound
when doing check-world.  It barely gets any win from parallelism:

$ time make -s check-world -j1 >/dev/null
     3809.60 real       584.44 user       282.23 sys
$ time make -s check-world -j2 >/dev/null
     3789.90 real       610.60 user       289.60 sys

Adding v2-0001-hack-use-template-initdb-in-tap-tests.patch:

$ time make -s check-world -j1 >/dev/null
     3193.46 real       221.32 user       226.11 sys
$ time make -s check-world -j2 >/dev/null
     3211.19 real       224.31 user       230.07 sys

(Note that all four runs have the "fsync = on" removed from
008_fsm_truncation.pl.)

So this looks like it'll be a nice win for low-end hardware, too.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Replace uses of deprecated Python module distutils.sysconfig
Next
From: Andres Freund
Date:
Subject: Re: slowest tap tests - split or accelerate?