Hi, On 2019-04-10 18:35:15 -0400, Tom Lane wrote: > on my workstation, this cuts the time for "make installcheck-parallel" > from 21.9 sec to 13.9 sec, or almost 40%. I think that's a worthwhile > improvement, considering how often all of us run those tests.
Awesome. > * The plpgsql test ran much longer than others, which turns out to be > largely due to the 2-second timeout in its test of statement_timeout. > In view of the experience reflected in commit f1e671a0b, just > reducing that timeout seems unsafe. What I did instead was to shove > that test case and some related ones into a new plpgsql test file, > src/pl/plpgsql/src/sql/plpgsql_trap.sql, so that it's not part of the > core regression tests at all. (We've talked before about moving > chunks of plpgsql.sql into the plpgsql module, so this is sort of a > down payment on that.) Now, if you think about the time to do > check-world rather than just the core regression tests, this isn't > obviously a win, and in fact it might be a loss because the plpgsql > tests run serially not in parallel with anything else. However, > by that same token, the parallel-testing overload we were concerned > about in f1e671a0b should be much less bad in the plpgsql context. > I therefore took a chance on reducing the timeout down to 1 second. > If the buildfarm doesn't like that, we can change it back to 2 seconds > again. It should still be a net win because of the fact that > check-world runs the core tests more than once. Hm, can't we "just" parallelize the plpgsql schedule instead? > Thoughts? Anyone object to making these sorts of changes > post-feature-freeze? Hm. There's some advantage to doing so, because it won't break any large pending changes. But it's also possible that it'll destabilize the buildfarm some. In personal capacity I'm like +0.5. Greetings, Andres Freund
