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