Re: Reducing runtime of stats regression test

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Date: 2017-05-04T13:54:49Z
Lists: pgsql-hackers
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 count from the immediately preceding
> statement to have gotten sent right then, and the count won't get
> sent at all while we're inside wait_for_stats (since backends only
> send stats just before going idle).  But there's more than one way
> to skin this cat.  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 table prevstats from temp to permanent; perhaps make it
unlogged?

I wonder if it'd be useful to have a "pg_stat_flush" or something, which
sends out whatever is queued in this session.  Then you wouldn't need
the reconnection.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Avoid hard-wired sleep delays in stats regression test.