Re: why is pg_upgrade's regression run so slow?

On 2024-07-27 Sa 10:20 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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?
>
>

Quite sure. Running crake and koel all it does. It's Fedora 40 running
on bare metal, a Lenovo Y70 with an Intel Core i7-4720HQ CPU @ 2.60GHz
and a Samsung SSD.

The culprit appears to be meson. When I tested running crake with
"using_meson => 0" I got results in line with yours. The regression test
times were consistent, including the installcheck tests.  That's
especially ugly on Windows as we don't have any alternative way of
running, and the results are so much more catastrophic.
"debug_parallel_query" didn't seem to matter.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com