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

From Robert Haas
Subject Re: slowest tap tests - split or accelerate?
Date
Msg-id CA+TgmoaOosjwS+j4f71Z4ha6Ki7X3D=vEK4p9vvZpXXhZ2i_+Q@mail.gmail.com
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
On Mon, Jan 17, 2022 at 1:41 PM Andres Freund <andres@anarazel.de> wrote:
> The reason these in particular are slow is that they do a lot of
> pg_basebackups without either / one-of -cfast / --no-sync. The lack of -cfast
> in particularly is responsible for a significant proportion of the test
> time. The only reason this didn't cause the tests to take many minutes is that
> spread checkpoints only throttle when writing out a buffer and there aren't
> that many dirty buffers...

Adding -cfast to 002_algorithm.pl seems totally reasonable. I'm not
sure what else can realistically be done to speed it up without losing
the point of the test. And it's basically just a single loop, so
splitting it up doesn't seem to make a lot of sense either.

pg_basebackup's 010_pg_basebackup.pl looks like it could be split up,
though. That one, at least to me, looks like people have just kept
adding semi-related things into the same test file.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Adding CI to our tree
Next
From: Robert Haas
Date:
Subject: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)