Hi,
On 2023-02-09 15:34:34 -0800, Peter Geoghegan wrote:
> Why not change the suite name to tmp_install? That immediately reminds
> me of what's really going on here, since I'm used to seeing that
> directory name. And it clashes with "--suite setup" in a way that
> seems useful.
The individual test is actually named tmp_install. I thought it might be
useful to add further things to the setup "stage", hence the more general
name.
I e.g. have a not-quite-done patch that creates a "template initdb", which
pg_regress and tap tests automatically use (except if non-default options are
required), which quite noticably reduces test times (*). But something needs to
create the template initdb, and initdb doesn't run without an installation, so
we need to run it after the temp_install.
Of course we could wrap that into one "test", but it seemed nicer to see if
you fail during installation, or during initdb. So for that I added a separate
test, that is also part of the setup suite.
Of course we could still name the suite tmp_install (or to be consistent with
the confusing make naming, have a temp-install target, which creates the
tmp_install directory :)). I guess that'd still be less confusing?
I'm not at all wedded to the "setup" name.
Greetings,
Andres Freund
* approximate test time improvements:
local:
688.67user 154.44system 1:08.29elapsed 1234%CPU (0avgtext+0avgdata 138984maxresident)k
->
172.37user 109.43system 1:00.12elapsed 468%CPU (0avgtext+0avgdata 139168maxresident)k
The 4x reduction in CPU cycles is pretty bonkers. To bad wall clock time
doesn't improve that much - we end up waiting for isolationtester,
pg_upgrade tests to finish.
CI freebsd: 06:30 -> 05:00
CI linux, sanitize-address: 5:40->4:30
CI linux, sanitize-undefined,alignment: 3:00->2:15
CI windows 12:20 -> 10:00
CI macos: 10:20 -> 08:00
I expect it to very substantially speed up the valgrind builfarm animal. By
far the most cycles are spent below initdb.
https://github.com/anarazel/postgres/tree/initdb-caching
