Re: why is pg_upgrade's regression run so slow? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: why is pg_upgrade's regression run so slow?
Date
Msg-id 1978062.1722090029@sss.pgh.pa.us
Whole thread Raw
In response to why is pg_upgrade's regression run so slow?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: why is pg_upgrade's regression run so slow?
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: proposal: schema variables
Next
From: Jeff Davis
Date:
Subject: Re: [18] separate collation and ctype versions, and cleanup of pg_database locale fields