Heikki Linnakangas <hlinnaka@iki.fi> writes:
> The elephant in the room is the 'timeouts' test, which takes about 40
> seconds, out of a total runtime of 90 seconds. So we'd really want to
> run that in parallel with everything else. Or split 'timeouts' into
> multiple tests that could run in parallel. I don't think grouping the
> rest of the tests differently will make much difference to how easy or
> hard that is.
The problem in "timeouts" is that it has to use drearily long timeouts
to be sure that the behavior will be stable even on really slow machines
(think CLOBBER_CACHE_ALWAYS or valgrind --- it can take seconds for them
to reach a waiting state that other machines reach quickly). If we run
such tests in parallel with anything else, that risks re-introducing the
instability. I'm not very sure what we can do about that. But you might
be right that unless we can solve that, there's not going to be much to be
gained from parallelizing the rest.
I wonder if there's some way to scale the timeout values based on
machine speed? But how would the test get that info?
regards, tom lane
