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 basicall
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 sure there's some bright line between adding
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
SQL-callable function
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 second.
> So you changed ta
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 co
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 basically get rid of them.
First up is this bit at the beginning of that