| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | why is pg_upgrade's regression run so slow? | 
| Date: | 2024-07-27 13:08:08 | 
| Message-ID: | b9d80722-6cb1-4793-bf2c-0324785abad9@dunslane.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2024-07-27 13:49:42 | Re: Pluggable cumulative statistics | 
| Previous Message | David Rowley | 2024-07-27 12:51:14 | Re: Speed up JSON escape processing with SIMD plus other optimisations |