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

Hello Andrew,

28.07.2024 22:43, Andrew Dunstan wrote:
>
> Maybe, IDK. Meanwhile, I disabled "debug_parallel_query = regress" on HEAD for fairywren and drongo -  fairwren has 
> just gone green, and I expect drongo will when it reports in a few hours.
>
> I'm at a loss for an explanation.
>

I'm observing the same here (using a Windows 10 VM).

With no TEMP_CONFIG set, `meson test` gives me these numbers:
test:         postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
duration:     72.34s

test:         postgresql:regress / regress/regress
duration:     41.98s

But with debug_parallel_query=regress in TEMP_CONFIG, I see:
test:         postgresql:regress / regress/regress
duration:     50.08s

test:         postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
duration:     398.45s

With log_min_messages=DEBUG2 added to TEMP_CONFIG, I can see how many
parallel workers were started during the test:
...\postgresql\build>grep "starting background worker process" -r testrun/pg_upgrade | wc -l
17532

And another interesting fact is that TEMP_CONFIG is apparently ignored by
`meson test regress/regress`. For example, with temp.config containing
invalid settings, `meson test pg_upgrade/002_pg_upgrade` fails, but
`meson test regress/regress` passes just fine.

Best regards,
Alexander