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