Re: test_json_parser/002_inline is kind of slow

From: Andres Freund <andres(at)anarazel(dot)de>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: test_json_parser/002_inline is kind of slow
Date: 2025-09-26 15:35:49
Message-ID: v73qc4nxhjgzyx4aysii3aas37cc2zsy5gozcwlick3g2cx6o2@veh7ewp22vge
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-09-26 15:38:03 Re: test_json_parser/002_inline is kind of slow
Previous Message Jacob Champion 2025-09-26 15:33:08 Re: test_json_parser/002_inline is kind of slow