Re: how to speed up 002_pg_upgrade.pl and 025_stream_regress.pl under valgrind

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: how to speed up 002_pg_upgrade.pl and 025_stream_regress.pl under valgrind
Date: 2024-09-15 18:31:13
Message-ID: 954609.1726425073@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> [ 002_pg_upgrade and 027_stream_regress are slow ]

> I don't have a great idea how to speed up these tests, unfortunately.
> But one of the problems is that all the TAP tests run serially - one
> after each other. Could we instead run them in parallel? The tests setup
> their "private" clusters anyway, right?

But there's parallelism within those two tests already, or I would
hope so at least. If you run them in parallel then you are probably
causing 40 backends instead of 20 to be running at once (plus 40
valgrind instances). Maybe you have a machine beefy enough to make
that useful, but I don't.

Really the way to fix those two tests would be to rewrite them to not
depend on the core regression tests. The core tests do a lot of work
that's not especially useful for the purposes of those tests, and it's
not even clear that they are exercising all that we'd like to have
exercised for those purposes. In the case of 002_pg_upgrade, all
we really need to do is create objects that will stress all of
pg_dump. It's a little harder to scope out what we want to test for
027_stream_regress, but it's still clear that the core tests do a lot
of work that's not helpful.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-09-15 19:16:27 Re: Trim the heap free memory
Previous Message Tom Lane 2024-09-15 18:22:14 Re: Trim the heap free memory