Andres, * Andres Freund (and...@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
signature.asc
Description: Digital signature
