Re: test_json_parser/002_inline is kind of slow - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: test_json_parser/002_inline is kind of slow |
Date | |
Msg-id | v73qc4nxhjgzyx4aysii3aas37cc2zsy5gozcwlick3g2cx6o2@veh7ewp22vge Whole thread Raw |
In response to | Re: test_json_parser/002_inline is kind of slow (Nathan Bossart <nathandbossart@gmail.com>) |
List | pgsql-hackers |
Hi, On 2025-09-26 10:25:19 -0500, Nathan Bossart wrote: > On Fri, Sep 26, 2025 at 11:11:52AM -0400, Robert Haas wrote: > > I've noticed that when I run 'meson test', the test mentioned in the > > subject line is usually the last one to finish. The test runs for 22 > > seconds on my machine, which is fairly high considering that 'meson > > test' in total (and with MESON_TESTTHREADS=8) runs for 3 minutes and > > 13 seconds. I think the reason for this relatively high runtime is > > that it fires off a separate shell command for each separate test, and > > there are 3400 of those. I'm not exactly sure what change to propose, > > but I wonder if we could come up with a way of making this a bit more > > efficient? Basically anything that would allow us to do multiple tests > > without having to fork a new process for every single one seems like > > it would probably save quite a bit. > > For some slow tests, we just have meson start it earlier with something > like this: > > + 'test_kwargs': {'priority': 40}, > > At least, that's enough to prevent it from completing last on my machine. > But actually improving the efficiency of the test seems like a better > long-term fix. It never finishes last here (linux, 20 cores) - and the overall runtime isn't that high, compared to the ones that finish last here [1] or are the slowest ones [2]. I'm not saying we shouldn't work on the efficiency of the test - forking thousands of times is pretty obviously absurdly inefficient - just that re-prioritizing doesn't seem that promising. Greetings, Andres Freund [1] 343/352 postgresql:test_json_parser / test_json_parser/002_inline OK 9.38s 3400 subtests passed 344/352 postgresql:ssl / ssl/001_ssltests OK 7.96s 247 subtests passed 345/352 postgresql:initdb / initdb/001_initdb OK 34.42s 57 subtests passed 346/352 postgresql:test_aio / test_aio/001_aio OK 11.71s 583 subtests passed 347/352 postgresql:pg_upgrade / pg_upgrade/006_transfer_modes OK 46.64s 60 subtests passed 348/352 postgresql:regress / regress/regress OK 57.33s 229 subtests passed 349/352 postgresql:pg_dump / pg_dump/002_pg_dump OK 45.00s 14236 subtests passed 350/352 postgresql:isolation / isolation/isolation OK 64.19s 122 subtests passed 351/352 postgresql:recovery / recovery/027_stream_regress OK 79.96s 11 subtests passed 352/352 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade OK 82.04s 19 subtests passed [2] 262/352 postgresql:pg_amcheck / pg_amcheck/003_check OK 19.46s 75 subtests passed 326/352 postgresql:pgbench / pgbench/001_pgbench_with_server OK 19.54s 467 subtests passed 297/352 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup OK 24.56s 200 subtests passed 345/352 postgresql:initdb / initdb/001_initdb OK 34.42s 57 subtests passed 349/352 postgresql:pg_dump / pg_dump/002_pg_dump OK 45.00s 14236 subtests passed 347/352 postgresql:pg_upgrade / pg_upgrade/006_transfer_modes OK 46.64s 60 subtests passed 348/352 postgresql:regress / regress/regress OK 57.33s 229 subtests passed 350/352 postgresql:isolation / isolation/isolation OK 64.19s 122 subtests passed 351/352 postgresql:recovery / recovery/027_stream_regress OK 79.96s 11 subtests passed 352/352 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade OK 82.04s 19 subtests passed
pgsql-hackers by date: