| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: Reducing runtime of stats regression test |
| Date: | 2017-05-04 13:54:49 |
| Message-ID: | 20170504135449.zepyxepq6ug5pgim@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-05-04 14:22:01 | Re: Reducing runtime of stats regression test |
| Previous Message | Craig Ringer | 2017-05-04 12:50:35 | Re: Function to move the position of a replication slot |