Re: [HACKERS] Reducing runtime of stats regression test
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Reducing runtime of stats regression test |
Дата | |
Msg-id | 20170504135449.zepyxepq6ug5pgim@alvherre.pgsql обсуждение исходный текст |
Ответ на | [HACKERS] Reducing runtime of stats regression test (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Reducing runtime of stats regression test
|
Список | 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
В списке pgsql-hackers по дате отправления: