Обсуждение: why is pg_upgrade's regression run so slow?
As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the normal regression tests. That in itself is sad, but what concerns me here is why it's so much slower than the regular run? This is apparent everywhere (e.g. on crake the standard run takes about 30 to 90 s, but pg_upgrade's run takes 5 minutes or more). On Windows, it's catastrophic, and only hasn't been noticed because the buildfarm client wasn't counting a timeout as a failure. That was an error on my part and I have switched a few of my machines to code that checks more robustly for failure of meson tests - specifically by looking for the absence of test.success rather than the presence of test.fail. That means that drongo and fairywren are getting timeout errors. e.g. on the latest run on fairywren, the regular regression run took 226s, but pg_upgrade's run of what should be the same set of tests took 2418s. What the heck is going on here? Is it because there are the concurrent tests running? That doesn't seem enough to make the tests run more than 10 times as long. I have a strong suspicion this is exacerbated by "debug_parallel_query = regress", especially since the tests run much faster on REL_17_STABLE where I am not setting that, but that can't be the whole explanation, since that setting should apply to both sets of tests. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes: > As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the > normal regression tests. That in itself is sad, but what concerns me > here is why it's so much slower than the regular run? This is apparent > everywhere (e.g. on crake the standard run takes about 30 to 90 s, but > pg_upgrade's run takes 5 minutes or more). Just to add some more fuel to the fire: I do *not* observe such an effect on my own animals. For instance, sifaka's last run shows 00:09 for install-check-C and the same (within rounding error) for the regression test step in 002_pgupgrade; on the much slower mamba, the last run took 07:33 for install-check-C and 07:40 for the 002_pgupgrade regression test step. I'm still using the makefile-based build, and I'm not using debug_parallel_query, but it doesn't make a lot of sense to me that either of those things should affect this. Looking at crake's last run, there are other oddities: why does the "check" step take 00:24 while "install-check-en_US.utf8" (which should be doing strictly less work) takes 01:00? Again, there are not similar discrepancies on my animals. Are you sure there's not background load on the machine? regards, tom lane