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

On Mon, Sep 16, 2024 at 6:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

027_stream_regress wants to get test coverage for the _redo routines
and replay subsystem, so I've wondered about defining a
src/test/regress/redo_schedule that removes what can be removed
without reducing _redo coverage. For example, join_hash.sql must eat
a *lot* of valgrind CPU cycles, and contributes nothing to redo
testing.

Thinking along the same lines, 002_pg_upgrade wants to create database
objects to dump, so I was thinking you could have a dump_schedule that
removes anything that doesn't leave objects behind. But you might be
right that it'd be better to start from scratch for that with that
goal in mind, and arguably also for the other.

(An interesting archeological detail about the regression tests is
that they seem to derive from the Wisconsin benchmark, famous for
benchmark wars and Oracle lawyers[1]. It seems quaint now that 'tenk'
was a lot of tuples, but I guess that Ingres on a PDP 11, which caused
offence by running that benchmark 5x faster, ran in something like
128kB of memory[2], so I can only guess the buffer pool must have been
something like 8 buffers or not much more in total?)

[1] https://jimgray.azurewebsites.net/BenchmarkHandbook/chapter4.pdf
[2] https://www.seas.upenn.edu/~zives/cis650/papers/INGRES.PDF