Andres,
* Andres Freund (andres@anarazel.de) wrote:
> There's also some tests simply taking way too long, e.g. the pg_dump
> tests just do largely redundant tests for 30s.
About half of the time in the pg_dump case, at least, appears to be in
010_dump_connstr.pl. I've not looked into it, but based on the test
names it does look like some of those tests might be redundant to what
is already being covered in 002_pg_dump.pl. Of course, the way the TAP
tests run, they require an initdb and startup of the postmaster, and
that's a somewhat fixed amount of time that any TAP test is going to
take.
I'm all for improving things certainly, though, well, while the pg_dump
tests do a lot, they also try to cover a good bit of the code in
pg_dump.c which is quite large. I wouldn't want to reduce our code
coverage just to make the regression tests go faster. The changes to
the pg_dump tests that I'm hoping to push soon will at least reduce the
output some, if not the length of time taken, while providing more code
coverage.
All that said, 30s out of 20m (which seems to more-or-less match what I
get locally too) makes me really wonder if that's the place that we need
to focus. Is it really the longest running test we have and it's just
that we have tons of them that are doing initdb over and over again?
> I'm not quite sure what the best way to attack this is, but I think we
> need to do something.
I tend to agree with this, though I haven't got any great answers,
unfortunately.
Thanks!
Stephen
