Re: regression coverage gaps for gist and hash indexes

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2023-04-02 12:38:32 -0400, Tom Lane wrote:
>> If they have to run serially then that means that their runtime
>> contributes 1-for-1 to the total runtime of the core regression tests,
>> which is not nice at all.

> Agreed, it's not nice. At least reasonably quick (74ms and 54ms on one run
> here)...

Oh, that's less bad than I expected. The discussion in the other thread
was pointing in the direction of needing hundreds of ms to make indexes
that are big enough to hit all the code paths.

>> Can we move them to some other portion of our test suite, preferably one
>> that's not repeated four or more times in each buildfarm run?

> Not trivially, at least. Right now 027_stream_regress.pl doesn't run other
> tests, so we'd not cover the replay portion if moved the tests to
> contrib/btree_gist or such.

Yeah, I was imagining teaching 027_stream_regress.pl to run additional
scripts that aren't in the core tests. (I'm still quite unhappy that
027_stream_regress.pl uses the core tests at all, really, as they were
never particularly designed to cover what it cares about. The whole
thing is extremely inefficient and it's no surprise that its coverage
is scattershot.)

regards, tom lane