Re: [HACKERS] Reducing runtime of stats regression test

2017-07-04 Thread Noah Misch
On Wed, May 03, 2017 at 11:43:43PM -0400, Tom Lane wrote: > On a reasonably fast development machine, one of the biggest time sinks > while running the core regression tests is the long "sleep" calls in the > stats.sql regression test. I took a closer look at these, and I think > we could

Re: [HACKERS] Reducing runtime of stats regression test

2017-05-04 Thread Tom Lane
Robert Haas writes: > On Thu, May 4, 2017 at 10:22 AM, Tom Lane wrote: >> Yes, but that would be getting into the realm of new features, not >> post-feature-freeze test adjustments. It certainly couldn't be >> a candidate for back-patching. > I'm not

Re: [HACKERS] Reducing runtime of stats regression test

2017-05-04 Thread Robert Haas
On Thu, May 4, 2017 at 10:22 AM, Tom Lane wrote: > Yes, but that would be getting into the realm of new features, not > post-feature-freeze test adjustments. It certainly couldn't be > a candidate for back-patching. I'm not sure there's some bright line between adding a new

Re: [HACKERS] Reducing runtime of stats regression test

2017-05-04 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> We can just start a new connection with \c, and >> let wait_for_stats wait for the old one to send its stats before quitting. >> Even on my oldest and slowest buildfarm machines, starting a new session >> takes well under one

Re: [HACKERS] Reducing runtime of stats regression test

2017-05-04 Thread Alvaro Herrera
Tom Lane wrote: > The other significant delay in stats.sql is > > -- force the rate-limiting logic in pgstat_report_stat() to time out > -- and send a message > SELECT pg_sleep(1.0); > > Now, we do seem to need a delay there, because the rate-limiting logic > is unlikely to have permitted the