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

On 2024-07-29 Mo 4:00 AM, Alexander Lakhin wrote:
> 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.
>
>

Well, that last fact explains the discrepancy I originally complained 
about. How the heck did that happen? It looks like we just ignored its 
use in Makefile.global.in :-(


cheers


andrew


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